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Captain  Saunders,  V’ance  .\[c.\Iillan.  M.S.,  Dcpariinent  (d  Cuinputer  Science  and 
Kngineeiing,  Wright  State  I'niversity.  1*)S9.  Explanation  Ceneralion  in  Icxpert  Sys¬ 
tems  (.\  Literature  Review  and  Implementation) 

Today's  technology  provides  tremendous  amounts  of  information  at  incrcxlihle 
speeds.  In  order  to  make  this  iid’orrnation  useful  for  more  complex,  signiheant 
irroblem  soh’ing  applications,  intelligent  computer  software  systems  are  needed.  1  lie 
Expert  System  (ES)  technology  of  .Artificial  Intelligence  (.AI)  is  one  solution  that  is 
etnerging  to  meet  this  need.  However,  as  this  technology  continues  to  develop  and 
as  we  begin  to  use  expert  machines  more  and  more,  it  is  crucial  that  we  demand  the 
same  explanatory  capability  from  these  mechanical  experts  as  we  do  from  human 
experts.  The  credibility  of  human  expertise  is  established  by  an  expert's  ability  to 
explain  his  expertise.  The  credibility  of  mechanical  e.^'^^ctise  must  be  established  in 
the  same  way.  .Additionally.  ESs  are  very  complex,  so;.  cated  systems.  In  order 
to  verify  their  accuracy  and  correctness,  ESs  must  be  able  to  explain  what  they  are 
doing  and  why. 

This  thesis  examines  the  Explanation  Facilities  (EFs)  of  ESs  by  first  conducting 
an  extensive  literature  review  of  this  topic,  and  second,  by  implementing  an  EF  for 
a  iraine  based  ES  shell.  The  purpose  of  the  literature  review  is  to  gain  a  general 
understanding  of  EF  research  and  development  while  th.f'  purpose  of  the  implemen¬ 


tation  elfort  is  to  investigate  the  specifics  of;  explaining  a  frame-based  ES.  adding 
an  EF  to  an  existing  anci  using  Aua  as  tne  implementation  language  tor  this  Al 
application. 
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Chapter  1 
Introduction 

1.1  Background 

[he  purpijsi/  ot  this  tlu'sis  is  to  ainiiie  tiie  tsplandtiou  nition  inpubilitif >  of 
expf'ft  systems,  i'liis  is  [)ase<l  on  the  need  to  (ieveiop  inttlliptiit  software  systems  in 
order  to  effectively  process  and  use  the  tremendous  amounts  of  data  that  technol- 
o”:y  (ajutinues  to  provide  and  to  develop  these  systems  using  sound  software  migi- 
neering  practices  and  [)rinciples.  One  technology  that  is  being  designed  to  provide 
rliese  nifflltfienl  software  systems  is  the  Expert  System  (ES)  technology  of  Artificial 
Intelligence  ( However,  as  the  technology  of  building  computeri~ed  experts  tran- 
"itions  more’  and  more  from  the  academic  laboratory  to  ditferent  operational,  ondine 
environments  (business,  industry,  defrn.se,  etc.),  the  importance  of  incorporating  the 
ab(;ve  mentioned  software  engineering  practices  into  the  development  of  these  ESs 
needs  to  be  re-emphasized.  Due  to  the  complexity  and  seriousness  of  the  problems 
E.Ss  are  being  developed  to  .solve,  we  simply  can’t  afford  the  cost  associated 
with  producing  systems  that  are  unreliable  or  produce  incorrect  results. 

this  thesis  examines  one  capability  that  provides  significant  contributions  to¬ 
wards  e.stablishing  the  credibility  and  reliability  of  ESs.  I'his  is  the  capability  ..-f 
ESs  to  explain  their  internal  processing  mechanisms  and  reasoning  processes  to  a 
human  user.  Interestingly,  we  retpiire  human  experts  to  pos.sess  this  capability  in 


order  tor  us  to  acci'i)!  their  expertise  as  h'gitiiuate.  It  is  e\'eii  iiioie  iinpiu'taiit  that 
we  require  these  same  caijal^ilities  from  cuiupiiterizc'd  { in  clm.i iciil]  experts. 

Ihis  examination  of  explanat it>n  generation  in  h'Ss  will  l.e  conducted  in  t\s<j 
|uirl'  I  he  first  part  conducts  a  relatively  intensive  review  ot  tlu-  .ivailaldc*  literature 
on  this  subject  in  order  tc'  oluain  a  basic  understaiuiing  ot  wIulI  is  being  done  in 
the  ar<‘a  of  explanat  ion  g<'neration  res<^arch  and  de\-elopment .  Ihis  information  is 
then  u-ed  in  tin'  second  i)art  of  this  thesis  to  dt'sign  and  impleiiu'ut  an  Ex[danation 
Facility  for  a  Framed:)ased  Expert  System  Sin'll  ( f'd'h  laSS )  using  t  lie  software  em 
'Aineenng  init'iisne  .A<la  [irogramming  language.  [Tliis  work  is  part  -d  a  larger  Aihi 
ml  \I  K'^earcli  ami  dev'elopment  effort  t'urreiitly  being  cornlucied  at  Wright  .Stati/ 
I  nivt'rsit  V, ! 

1.2  Literature  Review 

1  he  literature  rei. ;  ‘w  is  presentc'd  In  the  next  seven  chapter.s  of  fids  tju-sis.  It  l>egin,> 
in  Chapter  Ijy  [)r<.'ci.sely  defining  what  is  meant  by  expionni ion  (jf-iurntion  in  bSs. 
discussing  se\'eral  specihc  reasons  why  EFs  are  important  reciuirements  for  L.Ss,  and 
1)V  describing  a  Functional  Framework  in  which  to  analyze  the  FFs  of  FSs.  .Ml  of 
this  is  presented  for  the  purpose  of  establishing  a  common  ground  of  understanding 
t(;  tie  used  throughout  the  rest  of  the  thesis. 

Chapters  '■]  —  8  present  examinations  and  discussions  ot  several  different  efforts 
in  exnlanation  generation  research  and  development.  Chapter  3  discusses  the  work 
done  by  Fdward  Shortliffe  and  Bruce  Buchanan  on  the  MYCL\  expert  system.  I  his 
work  is  recognized  as  the  first  in  FF  research  and  development  and  ‘herel'ore  provides 
the  logical  [dace  to  begin  the  literature  review,  (.hapter  4  ('xamines  the  work  done 
oil  three'  FSs  that  are  direct  descendants  of  MYCIN.  Ihese  syste'iiis:  I  FIRFSI.AS. 
(11  !I)0.\.  and  .\lK).\ih  ( 'l.\  rc'presei'*  dilferent  efforts  to  increase  the  eth.'ctivencss 
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lit  Nn  ( 'IN  '  iiritiinal  I'.l' .  ( 'li<ipit'i'  ■")  Kj(jk.s  <it  I  he  <)iigoini>,  work  ut  W  illiain  Swarloui 
aiul  invoU't's  t  hroe  (litFeront  I'.Ss.  I'fx  Diijitdli.'i  I  hi  nipy  Advisor  \[ith  Explanations. 
till'  lirst  ot  ilicsc  systems,  was  coiieenusl  j)rimarily  with  ovf'rcoiiiing  some  of  tlu' 
limitations  ulent  itied  in  the  orimii.il  .\1\('I.\  Iff.  llowiwer.  the  two  systems  that 
tolhjweil  this  initial  work.  .XlM.Al.N  and  IflfS.  jirovide  sigiiilicant  new  aitj^roaehes  in 
f.l'  ile\-e!opment .  ('liapter  ti  (lisi  usses  th<'  work  lieimr  done  l)\-  H.  Chamlvasektiian 
and  ih'.il'  uith  tlie  lopie  ol  i/tninr  ///sA's  and  the  coiit rihiit ions  they  imd-ce  to  k.S 
de\-elo|)ment  and  ’lie  ai'iieratimi  ol  exphinal  ions,  t 'hapter  7  looks  at  three  indt'pen- 
deiit  elloits  m  Id'  [esoai'eh  and  development.  I  he  lirst  is  tlu'  work  ol  .1.  L.  Weiner 
m  Hl..\if.  1  he  foeiis  ol  this  elfoit  is  iti  developing  ways  to  rest  rnrt  nr(>  e.vpianatiiais 
m  order  to  reduce  their  comple.xity  and  th(.‘r<‘tore  tnake  them  easier  to  imilerstand. 

I  he  second  etfort  is  the  work  done  by  Robert  Kubinolf  in  ('L1£.\R.  1  he  [trimary 
locus  ot  Rnbitntlf's  work  is  in  [troducing  e.xplanations  of  terms  and  concepts  that 
aren't  understood  by  the  user  of  the  system.  The  third  effort  is  the  work  of  .Michael 
W  ick  and  .bum's  Slagle  in  JOE.  Of  interest  here  is  their  use  of  journalist  ic  principles 
it!  generating  explanations.  Finally.  Chapter  8  discusses  explanation  in  the  context 
of  Hc/ger  Schank  s  work  on  undtrstanding.  This  chapter  brietly  re-examines  each 
of  the  [jrevious  FfF  efforts,  and.  for  the  purpose  of  review.  e\aluates  each  of  them 
in  the  context  of  Schank's  undtrstanding  spectrum.  It  then  looks  at  some  [possible 
directions  for  future  FF  research  and  development. 

1.3  Implementation 

I  he  purpose  of  the  implementation  is  to  provide  hands  on  experience  in  designing 
and  fleveioping  an  EF  that  is  developed  in  .Ada  and  is  added  to  an  existing,  frame- 
baserl  F.S  shell.  Three  areas  of  interest  are  presented  in  discussing  this  project:  its 
scope,  the  FS  shell  it  use.s.  and  its  design  and  functionality.  Chapter  !)  defines  the 


of  l-'l-'Kl-’SS  hy  nient ilyirie  initial  n’qnir/'intnits  and  by  nsinii  llicsc  irijunc- 
nu'iits  tt>  liltt'r  through  the  literature  review  in  order  to  identify  those  conet^pls  and 
ideas  applicable  to  its  implementation.  Chapter  10  presents  a  detailed  e.xamination 
ot  the  frame-based  knowhdgf  irpnsf  ntation  .--tnirturf-  (KRS)  used  in  the  ES  shell. 
.\s  tins  is  th.e  primary  object  or  structure  that  is  to  Ire  e.xplainetl.  und<.“rstanding  it 
[rrecisely  is  important,  (.'hapter  1 1  then  cliscusst's  the  specific  design  of  EEKESS  and 
dt.'scibcs  (vich  of  the  functions  included  in  it.  This  chapter  also  analyzes  El'  h  ESS 
with  respect  to  the  Functional  Framework  presented  in  Chapter  2.  Ihese  three 
chapters  prcjvide  the  basic  examination  of  this  EF  implementation  efhu't.  How¬ 
ever.  one  hnal  chapter  is  provided  in  order  to  present  some  concluding  oi;ser\atioi;s 
concerning  the  EFFES'S  project  and  to  identify  some  areas  for  future  roearch. 


Chapter  2 


Establishing  A  Common  Ground 
Of  Understanding 

i 

I 

2.1  Overview 

The  purpose  of  this  chapter  is  to  establish  a  common  ground  of  understanding  upon 
u’luch  to  conduct  a  detailed  examination  of  EFs  (also  referred  to  as  explanation 
generation]  in  expert  systems.  This  will  be  done  by  first  defining  precisely  what 
we  mean  by  the  word  explanation,  second  by  discussing  several  major  factors  that 
establish  and  emphasize  the  importance  of  EFs,  and  finally  by  looking  at  the  three 
major  functions  that  must  be  considered  when  developing  an  EF. 

2.2  “Explanation”  Defined 

Before  we  can  begin  to  examine  the  work  that  has  and  is  being  done  in  the  area 

of  expert  system  EFs  it  is  important  that  we  understand  exactly  what  we  mean  by 

explanation.  The  Random  House  College  Dictionary  defines  explanation  as; 

"to  make  plain,  clear,  or  intelligible  something  that  is  not  known  or 
understood”.  [33] 

While  this  defines  the  basic  meaning  of  the  word  and  therefore  provides  the  basic 
purpose  of  an  EF,  Chandra.sekaran  et  al.  [8]  identifies  two  different  types  of  explana¬ 
tion  that  this  genera!  definition  encompasses  with  respect  to  ESs.  Thes«  two  types  of 


0 


explanation  are  explatniiuj  tin  world  and  (splatniinj  dtciston.^.  Explainnuj  tin  world 
relers  to  the  explaining  of  a  data  set  or  the  providing  of  logical  reconstructions  to 
show  how  certain  theories  are  explanations  of  some  observed  phenomena.  F.xpert 
systems  that  provide  these  types  of  explanation  are  concerned  with  the  objects  and 
processes  that  are  external  to  their  own  processing  mechanisms.  Examples  given 
were  diagnostic  type  ESs  such  as  DENDRAL  ll.o].  INTERNIST  [2.5].  and  RED  [20l. 
Explaining  ilecisions  on  the  other  hand,  riders  to  the  explaining  of  one's  own  deci¬ 
sions.  Expert  systems  that  provide  this  type  of  explanation  are  concerned  with  the 
objects  and  processes  that  are  internal  to  their  own  processing  mechanisms.  1  here 
are  many  ESs  that  provide  varying  degrees  of  this  type  of  explanation  also.  Several 
of  these  ESs  will  be  identified  and  discussed  in  subsequent  chapters  of  this  paper 
as  it  is  this  internal  type  of  explanation  that  we  are  interested  in  as  we  discuss  the 
Explanation  Facilities  of  ESs.  Therefore,  in  concurrence  with  Clancy,  Hasling,  and 

Rennels.  we  define  explanation  to  mean: 

"the  ability  of  a  program  to  discuss  what  it  is  doing  in  some  understand¬ 
able  way”.  [36.  page  3] 

,\n  EE  then,  is  the  mechanism  an  ES  uses  to  provide  this  explanation. 

2.3  The  Importance  Of  Explanation  Facilities 

The  first  step  in  establishing  the  importance  of  EFs  is  to  recognize  that, 

“Effective  methods  of  generating  explanations  of  both  system  queries 
and  conclusions  have  long  been  considered  an  important  feature  of  expert 
systems.”  [11,  page  xiv] 

While  some  of  the  first  ESs  did  not  have  EFs,  it  didn't  take  long  for  their  need  to  be 
identified.  As  the  domain  of  problem-solving  applications  to  w'hich  ESs  were  being 
applied  continued  to  grow  in  complexity  and  as  the  costliness  of  making  errors  in 
these  problem-solving  processes  continued  to  rise,  so  did  the  importance  of  EFs. 
Today,  EFs  are  considered  as  important  to  an  ES  as  its  knowledge  base,  control 


straU‘‘j,y.  or  iult-reiuiiig  iniHluuiisni.  hi  fact.  Fircbaugh  [IT],  while  idc'iit  ihiiig  i-'S:^ 
as  l)elonging  to  a  inor<'  gt'ueral  class  of  computer  systems  known  as  knowltdgt- 
ba^ni  ins.  emphasizes  the  fact  that  it  is  the  explanation  facility  of  an  ES 
that  distinguishes  it  from  other  knowledge-based  .\I  programs.  In  other  words,  an 
expert  system  without  an  explanation  facility  is  not  an  expert  system. 
Regardless  of  wliether  one  agrees  with  Firebaugh  or  not.  tew  individuals  (it  any) 
working  in  FS  research  and  development  will  argue  against  the  need  tor  FFs.  1  hcue 
are  four  major  reasons  why  this  is  true.  Three  of  these  reasons  are  explicitly  stated 
in  much  ot  the  literatuif'  on  <-xplanation.  The  fourth  is  implicitly  derived  from  the 
fundamental  goal  of  .\I.  We'll  begin  by  discussing  this  reason  first.  folK;W('d  by  the 
other  three. 

In  Ids  book.  .\RTirdCl.\L  I.\'TELL1GE.\'C E  Knowledge- Based  ■\pproach. 

Morris  W.  Firebaugh  states, 

"The  declared  goal  of  artificial  intelligence  research  is  to  teach  machines 
to  "think",  that  is.  to  display  those  characteristics  usually  associated 
with  human  intelligence."  [17,  page  .3] 

If  we  extrapolate  on  this  idea  with  respect  to  ESs  then  the  fundamental  goal  of  an  E,S 
is  to  think  like  a  human  expert;  to  display  those  characteristics  usually  associated 
with  a  human  expert.  .Accepting  this  to  be  true,  Swartout  and  Smoliar  [32]  identify 
four  basic  characteristics  of  a  human  expert  that  we  can  apply  to  ESs.  Paraphrased, 
these  four  characteristics  of  an  expert  are: 

1.  The  ability  to  solve  problems  within  his  domain  of  expertise. 

2.  The  ability  to  analyze  a  problem  statement  and  determine  whether  or  not  he 
is  capable  or  qualified  to  solve  the  problem  (whether  or  not  it  is  within  his 
reahn  of  expertise). 


3.  I  he  ability  to  explain  his  problem-solving  behavior. 


1.  I  he  ah'ility  to  adapt  his  prohh'iu-soiviiig  sli-ategies  to  new  and  unusual  situa¬ 
tions. 

If  w(>  are  to  achieve  our  fundaineiital  goal  of  btiilding  ESs  that  display  the  charac¬ 
teristics  of  a  human  expert  and  if  one  of  the  characteristics  of  a  human  (expert  is 
the  ability  to  explain  his  jtroblem  solving  process,  then  ESs  must  also  display  this 
characteristic. 

The  scx'ond  reason  EEs  are  important  stems  from  the  rationale  requiring  an 
expert  to  be  able  to  explain  himself.  Schank.  in  his  work  on  explanation  [27]  points 
out  that  we  humans  do  not  allow  other  human  beings  to  come  up  with  new  ideas, 
concepts,  etc.  unless  they  can  explain  thenaselves.  He  goes  on  to  say  that  while  we 
will  accept  unusual  or  unexplained  demonstrations  of  brilliance  for  a  short  while, 
eventually  we  will  begin  to  question  and  object,  thinking  that  somehow  we  are 
being  fooled.  Eventually  we  no  longer  accept  the  demonstrated  brilliance  as  being 
legitimate.  Thus,  experts  must  be  able  to  explain  themselves  because  we  humans 
require  it  in  order  to  have  confidence  in  what  they  are  telling  us.  EEs  satisfy  this 
same  requirement  for  ESs.  ('sing  the  EF,  human  experts  in  the  application  domain 
of  a  particular  ES  can  determine  if  the  system  is  performing  as  they  expect  it  to. 
thereby  assuring  themselves  of  its  credibility. 

While  reason  number  two  argues  that  we  humans  won’t  accept  ESs  that  lack 
an  explanation  facility,  reason  number  three  argues  that  we  can’t  accept  ESs  that 
lack  an  explanation  facility.  Says  Forsyth, 

■‘The  explanation  facility  should  not  be  regarded  as  an  optional  ex¬ 
tra.  Donald  Michie  (1982)  and  others  have  warned  about  the  dire  con¬ 
sequences  of  systems  which  do  not  operate  within  the  ’human  cognitive 
window’,  i.e.  whose  actions  are  opaque  and  inexplicable. 

If  we  are  to  avoid  a  succession  of  Three-Mile-  Island-type  disasters 
or  worse,  then  our  expert  systems  must  be  open  to  interrogation  and 
inspection.  In  short,  a  reasoning  method  that  cannot  be  explained  to  a 
person  is  unsatisfactory,  even  if  it  performs  better  than  a  human 
expert.”  [18,  page  14] 
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1  ho  [irohloiiis  .issociatocl  with  I  ho  dovolopment  ot  Crronoous.  uiiroliable.  and  uii- 
i!iaintainal>lo  software  sy.'tenis  is  one  of  the  most  serious  probleirts  in  the  field  of 
computer  science.  The  entire  Software  Engineering  discipline  is  dedicated  to  solving 
this  problono  ESs  that  do  not  have  a  capability  for  interrogation  and  inspection 
will  only  aggravate  and  complicate  the  problems  Software  Engineering  is  trying  to 
solve.  This  is  definitely  an  unacceptable  situation.  Thus,  the  third  reason  EEs  are 
important  is  because  they  provide  an  invaluable  debugging  tool,  allowing  knowledge 
engineers  and  system  designers  to  examine  the  ES  for  accuracy  and  correctness. 

The  fourth  reason  EEs  are  important  ran  almost  be  viewed  as  a  by-product  of  the 
previous  two  capabilities.  If  an  EE  can  explain  its  reasoning  process  to  an  expert  or 
its  control  structure  and  data  relationships  to  a  knowledge  engineer,  then  it  stands 
to  reason  that  a  novice  user  with  little  knowledge  of  the  application  domain  could 
use  this  same  information  as  a  learning/teaching  aide.  This  is.  in  fact,  the  case, 
and,  as  we  shall  see.  much  has  been  done  with  regards  to  explanation  generation 
and  tutorial  ES  applications. 

I'hese  then  are  the  major  reasons  EEs  are  considered  to  be  such  important 
components  of  ESs.  Let’s  now  look  at  the  three  functions  that  must  be  considered 
in  order  to  produce  them. 

2.4  Functional  Framework  For  Producing 
Explanations 

The  literature  identifies  three  major  functions  that  must  be  considered  in  order  to 
generate  or  produce  explanations  in  an  ES.  These  three  high-level  functions  consti¬ 
tute  the  basic  framework  in  which  all  work  on  explanation  generation  is  currently 
being  done.  Interestingly,  these  three  functions  (this  functional  framework)  are 
identified  in  the  literature  in  several  different  ways.  Clancy  et  al.  [36]  identifies 


them  as  f  pi.-iti  tuoloijic  i.--siifs.  itsi  r  inodthnij.  and  rlii  tone.  ( 'liaudrasekaran  et  al. 
[8]  id<>iitihes  them  as  ijennvtiny  fxplu  nations  basic  content,  nsponsi  vt  ntss.  and  the 
h  lumiu-coiupiitc  r  interjact.  Still  others  [14]  do  not  provitle  names  or  titles  for  these 
tiHK'tions  at  all.  For  ease  of  reference,  we  will  refer  to  them  as  Functions  I.  2.  and  3 
in  our  discussion.  However,  the  names  used  to  identify  these  functions  is  not  the  im¬ 
portant  issiK'  here  but  rather  the  understanding  of  their  contents  and  apjjlicat  ion>. 
high-level  descri[)tion  of  each  will  now  be  presented. 

Function  1:  Rememberitig  our  established  definition  of  e.Kplanat  ion.  the  content 
of  any  explanation  to  be  generated  is  based  on  the  internal  examination  (introspec- 
ticui)  ot  its  own  problem-soh'ing  mechanism  or  behavior.  Function  1  concerns  itself 
with  idenfilying  ways  to  ntodel  the  contents  of  this  problem-solving  mechanism  (the 
knowledge  and  reasoning  process  of  the  system).  This  is  the  foundation  of  the  en¬ 
tire  explanation  process  because  this  is  what  has  to  be  and  is  going  to  be  explained, 
'['his  is  the  primary  information  the  user  wants  to  know  about  and  the  developer 
wants  to  validate  and  check.  Therefore,  the  knowledge  and  reasoning  process  must 
be  represented  in  well  defined,  well  structured  methods  or  formalisms.  In  addition, 
these  methods  or  formalisms  must  be  appropriate  for  the  specific  problem-solving 
task  being  addressed  and  must  be  able  to  be  e.xamined  by  the  system.  However, 
attacking  this  modeling  process  from  the  knowledge  and  reasoning  process  level  of 
an  E.S  is  to  approach  it  from  a  very  high-level,  abstract  point  of  view  and  is  difficult 
to  do.  By  identifying  three  different  types  of  explanation  that  can  be  produced 
from  the  knowledge  and  reasoning  process  of  an  ES.  Chandrasekaran  et  al.  [S.9]  have 
provided  a  more  detailed  level  of  abstraction  from  which  to  attack  this  problem. 
These  three  types  of  explanation  are  now  described. 

1.  Type  1  explanations  are  concerned  with  explaining  why  certain  decisions 
were  or  were  not  made  during  the  execution  (runtime)  of  the  system.  These 


('xplanatioiis  use  int'oniiat ion  about  the  relationshijjs  that  <-'xist  between  pieces 
of  (.lata  atnJ  the  knowledge  (sets  of  rules  for  example)  available  for  making 
specific  decisions  or  choices  based  on  this  data.  For  example,  Rule  X  fired 
because  Data  \  was  found  to  be  true. 

Type  2  explanations  are  concerned  with  explaining  the  knowh'dge  base  ele¬ 
ments  themselves.  In  order  to  do  this,  explanations  of  this  type  must  look  at 
knoiL'Udge  about  knowledge.  For  example,  knowledge  may  exist  about  a  rule 
that  i(.lentifies  this  rule  (this  piece  of  knowledge)  as  being  applicable  ninet}’ 
percent  of  the  time.  .A  type  2  explanation  could  use  this  information  (this 
knowledge  about  knowledge)  to  justify  the  use  of  this  rule.  Other  knowledge 
used  in  provi(Jing  this  type  of  explanation  consists  of  knowledge  that  is  nsod 
to  develop  the  ES  but  uhich  does  not  effect  the  operation  of  the  svstem.  This 
type  of  knowledge  is  referred  to  as  deep  knowledge. 

d.  Type  3  explanations  are  concerned  with  explaining  the  runtime  control  strat¬ 
egy  used  to  solve  a  particular  problem.  For  example,  explaining  why  one 
particular  rule  (or  set  of  rules)  was  fired  before  some  other  rule  is  an  expla¬ 
nation  about  the  control  strategy  of  the  system.  Explaining  why  a  certain 
question  (or  type  of  question)  was  asked  of  the  user  in  lieu  of  some  other  log¬ 
ical  or  related  choice  is  another  example.  Therefore,  type  3  explanations  are 
concerned  with  explaining  how  and  why  the  system  uses  its  knowledge  the  way 
it  does,  a  task  that  also  requires  the  use  of  deep  knowledge  in  many  cases. 

These  three  types  of  explanation  help  divide  Function  1  concerns  into  more  specific, 
refined  sub-areas. 

Function  2:  This  function  concerns  itself  with  providing  an  explanation  to  the 
user  based  on  that  user’s  particulars  needs  and  abilities.  The  idea  here  is  that  every 
user  is  different.  Each  has  a  different  level  of  understanding  about  the  problem 


(lomaiii.  Lach  has  a  ilillerent  ivasou  lor  wanting  a  particular  (“,\|jlanatic.jn.  llascil 
on  these  dilFerenccs.  it  may  tiot  be  necessary  for  all  available  information  about  an 
explanation  to  be  provided.  One  way  that  this  is  accomplished  is  by  creating  a 
inodd  of  (hf  user  (a  database  of  knowledge  that  the  user  possesses)  and  then  using 
this  model  as  a  gage  for  determining  the  degree  of  explanation  to  present  to  that 
particular  user. 

Function  3:  This  function  concerns  itself  with  how  to  (xnivey  or  ]>resent  the 
information  to  the  user.  Should  natural  language  be  u.sed  or  will  source  code  state¬ 
ments  suffice?  W  hat  al)out  graphical  displays?  Should  text  and  graphics  be  com¬ 
bined?  These  are  the  types  of  questions  (or  concerns)  this  function  must  consider. 

This  section  has  described  a  functional  framework  for  generating  explanations. 
The  cpiestion  of  how  these  functions  are  being  achieved  is  addressed  in  subsequent 
chapters  of  this  thesis.  .Most  of  what  will  be  discussed,  however,  pertains  to  Func¬ 
tion  1.  The  reason  for  this  is  two-fold.  As  already  mentioned,  the  concerns  of  this 
function  constitute  the  foundation  of  any  explanation.  .N’o  matter  how  well  the 
user's  needs  and  abilities  are  understood  (Function  2)  and  no  matter  how  appropri¬ 
ately  the  explanation  can  be  displayed  (Function  -3),  if  the  information  content  of 
the  explanation  is  bad,  the  explanation  will  be  bad.  Furthermore,  from  a  purest 
viewpoint  of  explanation.  Function  I  deals  with  the  real  concerns  and  issues.  Deter¬ 
mining  how  to  model  the  internal  problem-solving  mechanisms  of  ESs  so  as  to  make 
them  available  for  explanation  and  examination  is  really  the  heart  of  explanation 
generation  research  and  development.  Therefore,  much  of  the  literature  available  on 
explanation  addresses  Function  I  type  concerns. 


2.5  Summary 


[  Ills  chapter  has  provided  a  conimon  ground  of  understanding  upon  which  to  con¬ 
duct  a  detailed  (examination  ot  the  work  that  has  and  is  bi'ing  doin'  in  the  lield 
of  (‘Xjilanat ion  generation.  .After  providing  a  specific  ih'finition  for  tin'  word  tspla- 
iKiliini  we  looked  at  tour  reasons  why  KFs  are  important.  ’['In'si'  ranged  from  the 
academic  desire  to  make  machiin'S  claiming  to  Ik'  fipt  iis  displav  tin'  ciiaracterist ics 
associated  with  human  ('.xperts.  to  the  establishment  of  an  IvK  as  tin'  nu'chanisrn  for 
instilling  confidence  and  credibility  in  its  expertise,  providing  a  debugging  and  test¬ 
ing  tool,  and  providing  the  nn'ans  for  instructing/teaching  less  knowh'dgeable  users 
about  the  problem  domain.  We  then  identified  and  discussed  the  three  functions 
that  make  up  a  functional  framework  for  generatitig  explanations.  These  inclitde 
the  conci'rns  related  to  modeling  the  knowledge  and  reasoning  process  of  the  E.S. 
determining  how  much  of  an  explanation  is  needed  b}'  a  given  user,  and  deciding 
how  to  present  the  explanation  to  the  user  in  a  form  that  will  be  easily  nndi'rstood. 


Chapter  3 

MYCIN:  The  Beginning 

3.1  Overview 

I  he  logical  place  to  begin  cnir  exainiiialion  ot  exj^lanalion  geru'ratioii  I'esearch  is  at, 
the  beginning,  with  the  bS.  M't'CIN  [2).  is  a  consnltation  syst('ni  designed 

to  diagnose  and  recotniuend  treatment  for  infectious  blood  diseases.  It  is  a  rule- 
based  production  system  that  uses  certainty  factors  to  handle  inexact,  ambiguous 
information  and  backward-chaining  (often  times  referred  to  as  a  hypothesis  dri\’en 
inference  mechanism)  as  its  control  strategy. 

We  will  examine  this  birthplace  of  EFs,  these  early  beginnings  of  explanation 
generation,  in  four  basic  parts.  First,  a  historical  synopsis  of  .M\’(.'I.\'s  development 
will  be  presented.  This  will  be  followed  by  a  high  level  discussion  of  the  first  basic 
assumptions,  general  characteristics  and  goals,  and  major  functional  areas  identified 
by  MYCTN’s  developers  as  necessary  for  any  EF.  We  will  then  examine  the  specifics 
of  this  1st  EF  a.r.d  follow  this  examination  with  a  discussion  of  the  accomplishments 
and  limitations  that  resulted  from  this  pioneering  work  in  explanation  generation. 

Buchanan  and  Shortliffe's  book  entitled  Rule-Based  Expert  Systems  [2]  is  a  com¬ 
plete  and  comprehensive  description  of  the  entire  MYCIN  project  and  is  the  primary 
source  of  information  for  this  chapter.  However,  the  information  I  have  extracted  is 
but  a  small  piece  of  this  extremely  significant  work  in  ES  research  and  development. 
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1  liii2,liK'  I'l'i'uii  1 1 1 K'lK  1  this  l)(M>k  to  an\'  iiUt'rcstcil  r('a<li‘r. 

3.2  Historical  Synopsis 

1  lie  '.nitial  ilisnissuins  that.  Itnl  to  tlie  M^CiX  proj('ct  woro  coiulurted  in  l!172  at 
Staiitord  I  m\(‘rsity.  1  lieso  discussions  involved  resea rclnu's  troin  the  I  ni\ersit\’ s 
.^ciiool  (d  Mediihne  aiul  ('oinputer  Scii'iicr'  Department.  Discussion  centert'd  on  de- 
xelupiiur  \va\  s  tu  add  intellitienci'  to  conpuiter  programs  l  hat  processed  medical  data. 
1  lu'  two  k<  phu'ers  that  emeri^ei.l  trom  this  collaborative  eilort  were  a  computer 
'lienti-t  named  Druce  Diichauaii  and  <i  metlical  student  named  Ivlward  .Short lille. 
In  laci.  the  div(  U'sion  of  i  he  icicutitu'd  lU'oblem  ami  the  ciunputer  system  that  was 
d'  n  I  'ii  )|)ed  a,'  It  '  'C  dut  ion  I  M  d  (  l.\  I  becailK'  t  1|<'  dll .  1) .  dlsM'i  t  at  Ion  ol  Shol  t  litfe  I  dl,l; . 

I'\  I'tTd  ShwiiliHe  h.ul  publislu'ii  ills  tlrst  journal  .irticle  .liioiit  .XH  ('l.\.  .\l  this 
tune  I  he  b.isic  knowledge  representation  and  ccuitrol  strati'gies  ol  MX  ('l.\  were  nda- 
ticc'ly  well  dec-eloped.  However,  the  HI''  e.xisted  in  onl>'  a  rudimeiitarv  state.  Short- 
litfe  had  developed  a  RI'Llh  commaml  that  c(.»uld  disjilav  a  spi citical  rule  onto  his 
te'-minal  screen.  I  lie  purjiose  of  t his  command  was  tor  debugging  the  knowledge 
base  where  the  rules  were  sim[)ly  echoed  hack  to  the  screen  in  their  origin  I  LISP 
lode  tormat.  .Alter  using  this  comiiiaml  tor  a  short  whih."  the  design  grou|)  r('al- 
i/ed  that  an  l-.nghsh  translation  ol  a  rule  would  provide  an  enhanced  explanation  of 
what  that  rule  was  doing,  in  addition  to  providing  a  partial  justification  for  the  ex- 
istence/use  (M  the  rute.  .Alrout  the  same  time  Sliort litfe's  first  article  was  |)ublished. 
( lorrv  published  an  article  about  the  work  Ix'iiig  done  ;it  M.  1.  1  .  on  a  program  for 
diagnosing  acute  renat  failure.  In  discussing  the  limitations  of  this  system.  (lorry 
identitied  the  lack  of  all  explanation  capability  as  the  most  serious  deficiency  of  tlie 
program.  This  article  inspired  Buchanan  and  ShortlifTe,  causing  them  to  hyirothe- 
size  that  ex{)lariat ion  was  not  only  invaluable  to  knowledge  engineers  (as  (iorry  hail 


iluirdi  l)Ut  was  alsc)  tlif'  rntical  link  ir'chIimI  to  |)ri)vi(l('  the  (uiitideiice  and  cri-diihilit \- 
a  runiputiT  >ystein  needs  in  order  to  Ire  used  and  accepted  by  physicians,  a  problem 
that  existing  medical  a.ssistanct'  programs  had.  In  fact,  as  Buchaitan  and  Sliortliffe 
--t  ati'  in  t  heir  liook. 

"We  were  especially  convinceal  that  explanation  capabilities  were  crucial 
for  ’wer  acceptance  and  that  this  single  failing  in  {tarticiilar  kirgely  ac- 
c(junteii  tor  the  reject imi  ot  systems  based  solely  on  statistical  approaches 
.  .  .  W('  could  not  prirvi*  that  explanations  would  make  a  ditference  urdess 
we  implenK’iited  a  consultation  system  in  a  clinical  envirotiiiu'ut  whe:> 
coiit  roiled  studies  coiihl  be  undertaken."  ['2.  page  b02] 

1  his  marked  the  begiiiniii”  of  explanation  g<’ri('rat ion  research.  So  imiiortanf  was 
it  belie\e(l  lo  be  tluo  from  I'tTil  through  I'lTo  it  was  the-  primtiry  re-.-earch  and 
de\-e!()pment  focus  of  the  group  at  Stanford  i’niversity  tha'  bc'came  known  as  t*ie 
M  )  (  l.\  ( 

3.3  Concepts  and  Fundamentals 

fhe  initial  assumptions,  concepts,  principles,  etc.  that  arc  developed  by  pioneers  in 
a  brand  new  area  of  research  are  often  tintes  very  important  because  they  form  the 
foiiridation  on  which  all  subsequent  research  is  based.  This  is  especially  true  in  ex¬ 
planation  generation  research.  In  an  effort  to  establish  this  foundation  with  respect 
to  our  discussion,  some  of  these  high  level  fundamental  ideas  are  now  discussed. 

3.3.1  Basic  Beliefs 

Four  basic  lieliefs  of  the  .\[}  ('l.\'  fiumj  formed  the  foundation  id  explanation  gener¬ 
ation  in  I'.Ss.  !28] 

1.  .\  consultative  rule-ba.sed  system  did  not  have  to  be  a  psychological  model 
that  precise'y  imitated  a  human's  rea.soning  process. 


1  he  inipm'taiit  gual  was  lor  !li<*  system  aiul  the  Ininian  exixnt  to  use  the  same 
tor  similar)  knowledge  about  the  application  domain  and  arrive  at  the  same 
lor  similar)  answer/decision  about  a  specific  problem. 

d.  1  he  process  of  the  system  trying  rules  and  taking  actions  was  equivalent  to 
the  human  reasoning  process. 

1.  If  inlormation  contained  in  the  rules  was  sufficient  to  show  why  an  acticui  had 
been  taken  (omitting  any  programming  details)  then  an  explanation  caudd 
simply  display  the  rule  verbatim  or  in  a  free-text  translation. 

These  lieliefs  formed  the  basis  on  which  the  EF  in  .M't’CIN  was  designed  and  imple¬ 
mented.  Remember,  however,  that  these  beliefs  were  not  unique  to  this  <levelopment 
elfort  hut  were  believed  by  this  team  of  researchers  to  be  universally  aiqjlicable  (even 
though  the  universe  of  explanation  generation  in  ESs  was  not  very  big  at  the  time). 

3.3.2  General  Characteristics  And  Goals 

The  general  characteristics  and  goals  identified  by  the  MYCIX  Gang  [2S]  have  al¬ 
ready  been  indirectly  described,  in  Chapter  2.  However,  they  are  restated  here  as  a 
necessary  building  block  in  the  construction  of  the  initial  foundation  of  EF  research. 

1.  The  basic  purpose  or  goal  of  an  EF  is  to  give  the  user  access  to  as  much  ol 
the  system’s  knowledge  as  possible. 

2.  .\n  EF  must  be  able  to  handle  questions  about  all  relevant  aspects  of  the 
system's  knowledge  and  actions. 

'■].  .\n  EF  must  provide  complete  and  comprehensive  answers  to  the  user. 

1.  .-\n  EF  must  be  easy  to  use  (for  novice  and/or  expert  alike). 


3.3.3  Major  Functional  Areas 


M\  (^IN's  (U'velopors  ideiilitied  two  primary  I'uiutions  a  consultative  expert  system 
EF  should  i)erform.['2S]  The  Hrst  they  called  the  Rtasoning  Status  Checker  (RSC) 
and  the  second  they  called  the  Genernl  Question  Answerer  (GQA).  While  these 
names  are  uniciue  to  the  MVCIN  project,  the  functions  associated  with  them  are, 
again,  ones  that  were  believed  to  apply  to  explanation  generation  in  general. 

I  he  HSC  is  used  during  the  actual  execution  of  the  consultation  session  and 
is  concerned  with  answering  questions  about  the  status  of  the  system's  reasoning 
process,  hxarnple.s  oi  these  types  oi  questions  are; 

•  WHY  is  the  system  reriuesting  a  particular  piece  of  information'.’ 

•  HOW  is  a  goal  or  subgoal  achieved'.^ 

In  order  to  answer  these  questions,  the  RSC  must  keep  track  of  what  the  system 
has  done.  It  needs  to  know  what  goals  and  subgoals  were  being  addressed  and 
which  rules  were  fired  to  achieve  a  specific  goal.  The  RSC  also  needs  to  have  a 
general  knowledge  of  how  the  rule  it^*rpreter  works.  Finally,  the  RSC  needs  to 
have  a  general  understanding  of  the  individual  rules.  It  needs  to  know  what  each 
rule  means  (or  know  where  to  look  for  this  meaning)  and  it  needs  to  know  what 
each  rule  is  used  for  —  the  goal  it  is  applied  against. 

The  GQ.4  is  used  during  and  after  the  consultation  session  and  is  concerned 
with  answering  questions  about  the  current  state  of  the  system's  knowledge  base. 
Examples  of  these  types  of  questions  are: 

•  WHAT  did  rule  X  tell  you  about  object  Y';’’ 

•  WHAT  is  the  value  of  parameter  X'^ 

•  HOW  d  id  you  use  the  attribute  value  of  object  X’! 


I't 


The  types  of  questions  that  can  be  asked  of  the  CQA  cover  a  much  wider  range  of 
possibilities  than  the  two  types  available  for  the  RSC.  Thereforei  the  GQA  must 
be  able  to  recognize  questions  from  this  much  larger  range  of  possibilities.  This 
often  involves  the  topic  of  natural  language  processing,  which  is  a  complicated  and 
complex  research  area  in  and  of  it.self.  However,  the  natural  language  processing 
problem  aside,  there  are  several  types  of  information  (or  knowledge)  the  GQA  must 
have  in  order  to  do  its  job.  Obviously,  it  must  have  all  of  the  knowledge  the  R.SC  has. 
[n  addition,  it  must  know  how  the  static  and  dvnamic  information  in  the  knowledi^e 
base  is  structured  and  stored. 

The  above  constitute  the  basic  concepts  and  beliefs  identified  by  tlie  MYCIN 
Gang  and  make  up  the  foundation  of  EF  research. 

3.4  MYCIN’s  EF 

.A.S  we  look  at  how  the  developers  of  MYCIN  incorporated  the  principles  and  con¬ 
cepts  identified  above  into  an  actual  EF,  we  will  do  so  in  more  detail  than  for  any 
other  EF  we  examine.  .Again,  this  has  to  do  with  the  fact  that  MYClN's  EF  was 
the  first  one  ever  developed  and  is  responsible  for  setting  the  standards  for  much  of 
the  subsequent  research  in  this  area. 

3.4.1  Specialists 

The  developers  of  MYCIN's  EF  tried  to  anticipate  all  of  the  types  of  questions  a 
user  might  ask  of  the  system.  They  then  created  specialists  (separate  pieces  of  code) 
to  answer  each  of  these  anticipated  questions  —  each  specialist  providing  one  type 
ot  explanation.  These  specialists  were  grouped  into  three  sets:  those  that  explained 
what  the  .system  was  doing  at  a  given  time,  those  that  explained  the  system's  static- 
knowledge.  and  those  that  explained  the  system's  dynamic  knowledge.  It  was  in 
these  different  sets  of  specialists  that  the  various  types  of  knowledge  required  by  the 
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RSC  and  CiQA  were  encoded. 

3.4.2  Knowledge  Organization 

MYC'lN's  knowledge  was  organized  into  four  basic  structures.  Fhe  first  was  the 
(ittrihntt  -ohjf  ct-v(due  triple,  a  conunon  data  storage  structure.  Second,  //.s/.s  were 
used  to  categorize  and  store  static  information.  Knowledge  tables  v,ere  the  third 
organizational  structure  and  were  u.sed  to  provide  cotnprehensive  records  of  certain 
parameters  and  the  values  these  parameters  could  have  under  various  situations. 
These  tables  helped  reducf'  me  complexity  of  many  of  the  rules  by  eliminating  the 
requirement  for  ivdes  dealing  with  multi-valued  parameters  to  have  to  conditionally 
check  each  possible  value  of  the  paranieter.  finally,  there  were  foui-  specialized  func¬ 
tions  that  were  used  for  comparing  and  manipulating  the  system's  parameters.  Each 
of  these  functions  had  a  specific  purpose  and  contained  the  necessary  knowledge  to 
fulfill  that  purpose. 

3.4.3  Rule  Structure 

To  provide  a  structure  for  grouping  and  categorizing  the  system's  static  and  dynamic 
knowledge,  developers  created  ten  context  types.  In  addition,  they  identi¬ 

fied  approximately  sixty-^ve  primitives  or  characteristics  of  these  different  context 
types.  Each  of  these  primitives  had  a  set  of  properties  associated  witli  it  that  de¬ 
scribed  such  things  as  the  legal  value  range  for  the  primitive,  the  list  of  all  rules  that 
used  the  primitive,  a  translation  of  the  primitive  into  its  English  representation,  etc. 
These  primitives  constituted  the  language  that  was  used  to  encode  all  of  MTCIN's 
rules.  By  having  a  small  set  of  well  defined  primitives  and  by  using  an  appropriate 
template.  .\IYCLN  was  able  to  provide  English-like  explanations  to  the  user. 


3.4.4  History  Tree 


The  history  tree  is  the  record  of  interactions  with  the  user  and  the  trace  of  the 
system's  performance  (as  required  by  the  RSC  and  GQA).  Because  of  MYCIN’s 
backward-chaining  control  strategy,  the  history  tree  reflects  this  goal-directed  solu¬ 
tion  approach.  Each  node  on  the  tree  is  a  goal  (or  subgoal)  and  contains  information 
about  how  the  system  tried  to  accomplish  that  goal  (i.  e.  Asked  the  user,  or,  Tried 
some  rule(s)).  In  addition,  each  rule  has  a  record  of  its  success  or  railure  and  a 
reason  why  it  failed,  should  that  be  the  ca^e.  Therefore,  one  can  see  the  wealth  of 
knowledge  contained  in  this  tree.  It  is  here  that  the  individual  specialists  look  for 
much  of  their  information.  By  starting  at  the  current  node  (the  current  goal  being 
addressed)  and  traversing  up  the  tree  to  its  root  the  'WHY  questions  of  the  RSC 
are  answered.  By  starting  at  the  root  of  the  tree  and  traversing  down  to  the  current 
goal  the  HOW  questions  of  the  RSC  are  answered. 

3.5  Accomplishments  And  Limitations 

3.5.1  Accomplishments 

The  most  important  accomplishment  of  the  MYCIN  project  is  the  identification 
and  establishment  of  the  need  for  ESs  to  provide  a  means  of  e.xplaining  themselves. 
Buchanan  and  Shortliffe  were  convinced  that  explanation  facilities  were  crucial  for 
user  acceptance  of  consultative  expert  systems  and  set  out  to  prove  that  this  gut 
feeling  was  correct.  In  1980  they  conducted  a  formal  analysis  of  physicians’  attitudes 
concerning  this  subject.  The  details  of  this  study  are  described  in  [2,  Chapter  34). 
However,  the  pertinent  information  from  this  study,  with  respect  to  our  discussion, 
is  that  the  ability  of  a  computer  program  to  provide  explanations  about 
its  reasoning  process  was  determined  to  be  the  single  most  important 
requirement  for  a  medical  advice-giving  system. 


Another  important  result  of  the  MYCIN  work  is  the  foundation  for  explanation 
generation  established  by  this  project.  The  basic  characteristics  and  goals  identified 
for  EFs  are  still  considered  applicable  today.  The  structuring  of  knowledge,  use  of 


teiiiplates  lor  Eiigliw.it*lilvC  explanation  genciatiOii,  and  tiic  ouilciiii^  ui  ct 
are  all  initial  ideas  that  are  still  in  use. 


tree 


3.5.2  Limitations 

Almost  as  important  as  its  accomplishments  are  .MYCIN's  limitations,  for  it  is  the 
identification  of  these  limitations  that  provides  the  fuel  for  further  investigation  and 
research.  Subsequent  chapters  of  this  thesis  will  examine  the  research  that  has  been 
conducted  and  the  systems  that  have  been  developed  to  overcome  or  improve  upon 
these  limitations. 

Hasling,  Clancy,  and  Rennels  [36]  identify  the  first  major  limitation.  MYCIN 
is  unable  to  explain  the  strategy  it  used  to  solve  a  particular  problem.  This  is 
primarily  due  to  the  fact  that  the  strategy  information  is  implicitly  contained  in  the 
rule  orderings  of  the  system  and  is  unavailable  for  explanation.  When  the  knowledge 
engineers  encoded  the  expert  knowledge  (the  rules)  certain  rules  were  identified  to 
be  tried  before  others.  This  ordering  was  based  on  knowledge  that  was  obvious 
to  the  expert  (often  times  resulting  from  the  expert’s  experience  with  the  subject 
matter)  but  was  not  explicitly  encoded  into  the  system  and  therefore  unavailable  for 
explanation.  Yet  being  able  to  explain  this  strategy  adds  credibility  to  the  human 
expert  and  would  do  the  same  for  a  computer  program. 

Swartout  [35]  identifies  a  second  limitation,  one  that  is  closely  related  to  the  first. 
This  limitation  is  .MYCIN’s  inability  to  justify  its  actions.  The  system  can  describe 
what  it  did  by  using  its  execution  trace/ history  tree,  but  it  can’t  explain  why  its 
actions  are  reasonable  in  terms  of  domain  principles.  Again,  the  reason  for  this  is 
that  this  information  is  implicitly  contained  within  the  structure  of  the  system  and 
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can't  be  used  by  tlie  EF. 

A  third  limitation  is  identified  by  Rubinoff  [26].  He  notes  tliat  MVCI.N  can't 
explain  its  concepts  and  terms,  explanations  that  are  needed  when  a  user  is  confused 
about  what  the  system  is  asking. 

The  fourth  limitation,  identified  by  Swartout  [34].  concerns  itself  with  MYClN's 
inefhcient  handling  of  change  and  revision  to  a  previously  provided  answer.  While 
.MYCTN  readily  accepted  the  changed  answer,  it  would  then  recompute  the  en¬ 
tire  consultation  process  thereby  re-executing  many  unaffected  steps  and  providing 
explanations  to  the  user  that  contained  large  amounts  of  redundant,  irrelevant  in¬ 
formation. 

The  final  limitation,  again  identified  by  Swartout  [34].  concerns  itself  with  the 
small  knowledge  limit  conveniently  expressable  in  a  single  rule.  Swartout  credits 
Randall  Davis  for  making  this  discovery  in  his  work  on  meta-knowledge  (some  of 
Davis'  work  will  be  discussed  in  the  next  chapter).  When  actions  to  be  accomplished 
are  larger  than  can  be  expressed  in  a  single  rule,  the  combination  of  several  rules  is 
used.  Often  times,  accurately  constructing  and  relating  these  rules  to  achieve  the 
intended  action  is  difficult  to  do. 

3.6  Summary 

In  analyzing  MYCIN  with  respect  to  the  Functional  Framework  described  in  Chapter 

2  we  find  that  two  of  the  three  functions  were  addressed  to  some  degree.  The  history 
tree  provided  the  Type  1  explanations  of  the  first  function.  However,  Type  2  and 

3  explanations  were  not  provided.  The  combination  of  rule  structure  and  template 
provided  the  requirement  for  Function  3.  The  English-like  explanations  of  this  first 
EF  were  cjuite  an  accomplishment. 

■MYClN’s  original  purpose  was  to  provide  a  solution  to  the  problem  of  adding 


iutelligeiu'e  to  computer  programs  that  processed  medical  data.  Early  in  its  devel¬ 
opment  stage,  a  second  purpose  was  identified.  The  lead  architects  of  the  system 
wanted  to  prove  that  their  gut  feeling  regarding  the  importance  ot  e.xplanation  for 
user  acci'ptance  was  correct.  .M'tCIN  has  successfully  fulfilled  both  of  these  pui- 
poses.  More  importantly,  it  has  recognized  and  led  the  way  into  an  e.xtremely 
important  area  of  ES  research  and  development  —  the  generation  of  explanations 
—  providing  the  capability  for  an  ES  to  explain  how  and  why  it  does  what  it  does. 


Chapter  4 

The  MYCIN  Family: 
TEIRESIAS,  GUIDON,  and 
NEOMYCIN 


4.1  Overview 

As  identified  in  Chapter  3.  explanation  generation  research  became  a  primary  focus 
of  attention  shortly  after  the  initial  MYCIN  project  began.  This  was  due  in  large 
part  to  the  numerous  limitations  identified  in  MYCIN’s  EF.  The  purpose  of  this 
chapter  is  to  describe  the  various  research  efforts  that  resulted  directly  from  the 
initial  MYCIN  system.  All  of  the  systems  we  are  going  to  discuss  in  this  chapter  are 
directly  related  to  MYCIN.  For  the  most  part  they  use  the  knowledge  representation 
schemes,  inferencing  mechanisms,  etc.  already  established  in  MYCIN.  .Assuming 
MYCIN  to  be  Version  I  of  EFs,  these  systems  constitute  Version  2  —  the  first 
upgrade  to  the  initial  system.  As  will  be  identified,  the  motivation  for  these  systems 
varies.  However,  each  was  developed  to  increase  the  power  and  application  of  the 
initial  system  by  enhancing  its  explanation  generation  capabilities. 


2.5 


4.2  TEIRESIAS 

4.2.1  Background 

TEIRESIAS  was  developed  by  Randall  Davis  [2.  Chapters  9  and  17]  to  provide  an 
automatic  acquisition  mechanism  for  the  addition  of  new  knowledge  to  M'l'CIN's 
knowledge  base.  It  was  designed  as  a  front-end  or  ancillary  system  to  MYCL\ 
and  was  concerned  primarily  with  the  user  interface  needed  to  provide  this  desired 
capability.  Flowever.  the  need  to  provide  enhanced  explanation  for  debugging  and 
testing  of  added  knowledge  was  also  recognized  and  provided  the  motivation  lor  the 
research  we  are  going  to  examine. 

4.2.2  Contributions 

There  were  two  primary  contributions  to  EF  research  that  resulted  from  the  TEIRE¬ 
SIAS  project.  The  first  was  the  concept  of  an  information  metric  to  help  provide 
varying  degrees  of  explanation  detail  to  the  user.  The  second  was  the  formal  defi¬ 
nition  of  four  steps  needed  to  design  an  EF. 

Function  2  of  the  Functional  Framework  described  in  Chapter  2  is  concerned  with 
presenting  explanations  to  the  user  ba.sed  on  their  individual  needs  and  abilities. 
The  information  metric  [14,  page  269]  developed  by  Davis  was  the  first  attempt 
at  providing  a  capability  in  this  area.  Using  the  Certainty  Factors  (CF)  already 
associated  with  the  knowledge  in  the  knowledge  base,  Davis  chose  -(log  CF)  to 
represent  his  information  metric,  his  measuring  device  on  how  much  or  how  little 
explanation  to  provide  to  the  user.  This  value  was  not  based  on  any  formal  theory 
or  justification  of  meaningfulness  and  didn’t  account  for  the  user's  knowledge  about 
the  application  domain.  It  wa.s  simply  a  dial  available  to  the  user  to  adjust  the 
level  of  detail  provided  in  an  explanation.  The  way  this  metric  functioned  was  also 
quite  simple.  The  distance  from  the  current  node  in  the  execution  trace/history 


tree  to  the  top  ot  this  tree  was  computed  and  normalized  to  10.  The  user,  it  he  so 
desired,  input  a  number  that  was  taken  as  a  fraction  of  this  normalized  distance  and 
explanation  from  the  current  node  to  that  level  in  the  tree  was  provided,  .\gain. 
this  whole  idea  wasn’t  founded  in  any  scientific  theory.  However,  its  implementation 
was  considered  a  success. 

The  second  contribution  identified  above  was  the  four  design  steps  Davis  formally 
identified  as  being  necessary  to  design  an  EF.  [14.  page  264]  These  tour  steps  are: 

1.  Determine  the  program  operation  that  is  to  be  viewed  as  primitive. 

In  the  case  of  TEIRESTTS  (and  MYCIN)  this  primitive  operation  was  the 
invocation  of  an  individual  rule. 

2.  Augment  the  program  code  to  leave  a  trace  or  record  of  the  system’s 
behavior  at  the  level  of  detail  chosen  in  (1).  The  history  tree  of  goals 
and  rules  provided  this  capability. 

3.  Select  a  global  framework  in  which  the  trace  or  record  can  be  un¬ 
derstood.  Davis  chose  a  goal  tree  and  provided  a  set  of  commands  for  this 
framework.  This  choice  was  based  on  the  backward-chaining  control  structure 
used  in  MYCIN.  However,  different  frameworks  can  be  identified  for  different 
system  designs. 

4.  Design  a  program  that  can  explain  the  trace  or  record  to  the  user. 

Implement  the  set  of  commands  identified  in  (3). 

As  EF  research  has  grown  and  expanded  and  as  additional  requirements  for  EFs 
have  been  identified,  these  design  steps  have  also  expanded  and  grown.  However,  as 
will  be  seen  in  the  following  chapters,  these  four  steps  are  still  relevant  today. 


4.2.3  Limitations 


In  clt'signing  lEIRESIAS's  EE  based  on  the  above  steps,  Davis  identified  several 
limitations  to  the  S3stem.  Eirst,  the  choice  of  a  single  primitive  operation  and  a 
single  framework  restricted  the  class  of  events  that  could  be  ex[)lained.  In  addition. 
onl\'  snrtace  level  (unsophisticated)  explanation  could  be  given.  Eor  example,  the 
svsti'ui  only  interpreted  the  meaning  of  WHY  one  way  and  provided  its  explanation 
based  on  this  interpretation.  However,  there  are  several  different  interpretations  of 
this  word.  l  EIRESEAS's  EE  couldn't  handle  these  different  VVH\’s.  Einallv.  Da\is 
noted  that  no  capability  existed  to  explain  the  control  flow  or  solution  strategy  id 
the  problem  solving  process. 

4.2.4  Conclusion 

The  primary  importance  of  the  TEIRESI.4S  project  was  involved  with  the  auto¬ 
matic  knowledge  acquisition  capability  it  provided  to  hn'CIX.  .As  this  was  beyond 
the  scope  of  this  paper,  it  was  not  discussed.  However,  this  does  not  reduce  the 
sigidficance  of  the  EF  accomplishments  we  have  identified  above.  .As  has  already 
been  mentioned,  the  formal  design  goals  identified  are  still  relevant  todav’.  While 
nothing  in  the  literature  indicates  how  effective  the  information  metric  was  (except 
to  say  that  it  was  successful  ),  it  is  definitely  a  part  of  the  MYCIN  system  and  is 
mentioned  frequently  by  those  developing  other  ideas  in  this  particular  area. 

In  analyzing  TEIRESIAS  from  the  point  of  view  of  our  F'unctional  Framework 
described  in  Chapter  2,  we  find  that  this  system  provided  MA’CEN  with  an  increased 
Function  2  capability,  the  information  metric. 


4.3  GUIDON 


4.3.1  Background 

.\[\  ('I\'s  success  as  a  problem  solver  of  infectious  blood  disease  diagnosis  seemed 
to  indicat*'  that  its  knowledge  base  was  rich  enough  to  provide  a  source  of  material 
for  teaching  students  about  this  application  domain.  William  Clancy  was  out.’  of  the 
inili\  idual.s  that  believed  this  to  be  true  and  was  the  primary  architect  of  CJl’IDON 
[2.  Chapters  26  and  29]  [10],  a  system  designed  to  be  a  tutorial  version  ol  NH'Cl.X. 

4.3.2  Problems  Encountered 

Initially.  Clancy  felt  that  a  simple  restructuring  ol  MYCIX's  rules  was  basically 
all  that  would  be  needed  to  provide  a  tutorial  capability.  However,  he  soon  dis¬ 
covered  this  was  not  the  case.  .MYCI.M  was  developed  with  e.x'i^ert  us(‘rs  in  mind 
(practicing  physicians)  —  tutoring  involves  explanations  to  naive  users  (medical 
students).  .Much  of  the  knowledge  Clancy  needed  to  have  available  for  explanation 
was  not  there.  For  example,  the  expert  diagnostic  approach  and  understanding  of 
the  rules  that  was  used  to  build  the  system  was  not  explicitly  encoded.  I'he  rules 
could  not  be  justified  because  the  concepts  of  how  the  rules  fit  together  were  not 
explicitly  identified.  The  problem  solving  strategy  could  not  be  explained  because 
the  structure  of  the  search  space  and  the  strategy  for  traversing  it  were  implicitly 
contained  in  the  ordering  of  the  rules.  Because  of  these  missing  pieces  of  knowledge 
needed  to  provide  a  tutorial  program.  Clancy  (and  others)  conducted  a  detailed  re¬ 
examination  of  .VIYCTN’s  rule  base  and  the  foundations  upon  which  the  rules  were 
constructed,  ’['his  re-examination  resulted  in  identifying  .several  important  concepts 
and  ideas  that  have  subsec|uently  b«x?n  applied  beyond  the  tutorial  environment  in 
which  thev  were  discovered. 


4.3.3  New  Concepts  And  Enhancements 


I  he  lirst  identitied  .vas  that  of  .'.tmte(jij.  (Maury  df'liiied  tliis  concept  as  a 

plan  by  w'  ch  goals  and  hypotheses  are  ordered  in  a  proltlein  solving  proc<*ss.  This 
concept  i-^  important  tor  an  KS  to  l)e  able  to  explain,  but  ktuiudedge  about  this 
strategy  must  be  explicitly  provided  in  order  to  do  so.  .A  second  conce|)t  was  that 
ot  st ructui'dl  knuU'Udgt.  (Maiicy  defined  this  concept  as  abstractions  that  are  used 
to  index  into  the  domain  knowledge,  to  provide  a  handle  by  which  a  strategy  can  lie 
applic'd.  third  concept  was  that  of  support  knowledge.  (Mlancy  defined  this  concept 
as  low-le\'el  intormation  that  iih'iit ih(>s  the  causal  relationships  between  dilferent 
types  ot  structural  knowledge.  1  hc'se  tliri'e  concepts,  which  CMancy  identified  as  the 
■■'trahgg/stnicture/support  framework,  were  a  major  break  through  in  EF  research. 

Having  identified  this  framework.  Gl  IDO.N’  s  developers  then  set  about  figuring 
out  ways  to  encode  this  knowledge  into  the  .MYCI.N'  knowledge  base.  The  method 
chosen  was  to  use  domain-independent  meJa-rules  to  explicitly  specify  the  problem¬ 
solving  strategies.  While  a  detailed  discussion  of  meta-knowledge  and/or  metn-rule.i: 
is  beyond  the  scope  of  this  paper  (.see  [13]  for  complete  details),  in  <i  nut  shell. 
nifta-knowltdge  is  knowledge  about  knowledge  and  meta-rules  are  rules  about 
rules.  From  an  abstraction  level  point  of  view,  domain  knowledge  and  domain  rules 
are  the  lowest,  most  detailed  level  of  knowledge  abstraction  in  the  system.  Meta¬ 
knowledge  is  at  a  higher  level  of  abstraction  and  is  used  to  explain  the  knowledge 
at  the  lower  level.  This  was  precisely  what  CMancy  needed. 

4.3.4  Conclusion 

In  analyzing  the  work  done  in  this  sy.stern  with  respect  to  our  Functional  Framework 
o[  (Miapter  2.  we  find  that  all  of  it  pertains  to  knowledge  representation,  a  Function 
1  application.  ITierefore.  GITDON  enhanced  the  Function  1  capabilities  of  M\’GL\. 
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riu'  mo>t  (.liHiuatif  discovf'ry  resukiug  from  the  GUIDON  sy.st<Mii  was  that  one 
eaii  I  simply  add  an  interaetive  front-end  onto  any  AI  program  (especially  an  LS) 
and  expect  it  to  be  an  adec[uate  and  effective  instruction  mechaidsm.  In  order  to 
he  etfectiv('  tutors.  DP's  must  do  more  than  just  read  back  their  reasoning  steps 
and  be  al)le  to  recognize  (luestions.  They  must  be  able  to  abstract  the  n'asoning 
steps  and  relate  them  to  the  domain  models  and  problem  solving  strategies  tlu'y 
use.  (.'lancy's  identification  ol  the  strategy/structure/support  fnunt  H'oi-k  in  response 
to  this  problem  has  become  one  of  the  most  significant  rnoti\ators  of  explanation 
generation  research  in  th('  field. 

4.4  NEOMYCIN 

4.4.1  Background 

The  developers  of  NEOMYCIN;  Hasling,  Clancy,  and  Rennels  [36].  hypothesized 
that  an  understander  (as  they  called  it)  must  have  an  idea  of  the  problem-solving 
process  and  domain  knowledge  in  order  to  understand  and  solve  the  problem  him¬ 
self.  With  this  in  mind,  these  individuals  set  out  to  develop  a  knowledge  base 
that  facilitated  recognizing  and  explaining  diagnostic  strategies.  Interestingly,  this 
sounds  vaguely  familiar  to  the  previous  section  on  GUIDON.  One  readily  recognizes 
Clancy's  name  on  both  projects.  Not  surprising  then  that  much  of  the  work  on 
these  systems  overlapped. 

4.4.2  Problems  Encountered 

Basically  the  problems  encountered  were  the  same  as  those  encountered  in  GUIDON. 
Knowledge  of  the  diagnostic  approach  and  understanding  of  the  rules  were  not 
available  for  explanation.  .Neither  were  the  concepts  of  how  the  rules  fit  together  or 
the  structure  of  the  search  space  or  the  strategy  for  traversing  it. 
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4.4.3  Enhancements/ Achievements 

The  first  important  achievement  resulting  from  this  project  was  the  formal  recog¬ 
nition  of  the  need  for  understanding  and  being  able  to  explain  problem-solving 
strategies.  Second  was  the  realization  that  separating  control  knowledge  trom  do¬ 
main  knowledge  was  extremely  important,  as  was  explicitly  representing  this  control 
knowledge  in  abstract  ndes.  Finally,  and  most  importantly,  was  the  development 
of  the  task  concept.  .A  tank  is  a  representation  hierarchy  ot  meta-level  goals  and 
subgoals.  Remembering  that  rneta-rules  are  used  to  explicitly  encode  the  control 
knowledge  into  abstract  rules,  these  meta-rules  are  the  methods  used  to  achieve  the 
goals  and  subgoals  in  a  task.  These  meta-rules  invoke  other  tasks  which  use  their 
meta-rules  to  achieve  their  goals  and,  in  turn,  invoke  other  tasks,  etc.  until  ulti¬ 
mately  the  gram  level  interpreter  is  invoked  to  pursue  domain  goals  using  domain 
rules.  This  whole  concept  of  tasks  is  an  interesting  one  and  will  be  discussed  in 
greater  detail  in  Chapter  6'. 

4.4.4  Conclusion 

In  viewing  NEOMYCIN  from  our  Functional  Framework  point  of  view  we  find  the 
same  application  as  in  the  GUIDON  system.  Strategic  explanations  deal  with  Func¬ 
tion  1.  Type  3  explanations. 

Providing  strategic  explanations  was  the  primary  focus  and  importance  of  the 
.NEOMYCIN  project.  Interestingly,  providing  these  explanations  is  not  much  differ¬ 
ent  than  providing  explanations  about  the  application  domain.  Fhe  only  difference 
is  that  strategic  explanation  takes  place  at  a  higher  level  of  abstraction  than  do¬ 
main  explanation.  .Another  interesting  point  is  that  understanding  domain  level 
concepts  is  an  important  prerequisite  to  understanding  and  appreciating  strategic 
explanations. 


4.5  Summary 


This  chapter  has  discussed  three  areas  of  explanation  generation  research  that  were 
based  on.  and  the  immediate  result  of.  the  initial  MYCIN  program. 

TFTRESl.AS.  designed  as  a  front-end  knowledge  acquisition  interface  to  .MA’C.'l.X. 
was  concerned  with  user  interaction.  .As  a  result,  its  contribution  to  EF  research 
dealt  with  providing  varying  degrees  of  explanations  based  on  the  users'  desires  and 
input. 

GITDOX.  designed  to  expand  .MYCIN  into  a  tutorial  system  for  medical  stu¬ 
dents.  discovered  that  the  original  knowledge  representation  schemes  in  .MVCI.N 
were  not  robust  enough  to  support  a  teaching  environment  (an  environment  that 
deals  with  naive/novice  users).  In  addition,  much  of  the  knowledge  needed  to  pro¬ 
vide  tutorial  type  explanations  was  implicitly  hidden  in  the  knowledge  base  and 
therefore  unavailable  for  explanation.  These  deficiencies  in  the  original  system  mo¬ 
tivated  extensive  analysis  and  research  which  led  to  the  development  of  the  strat¬ 
egy /st  met  u  re  /s  u  p  po  rt  fra  me  wo  rk. 

.\E0.\I\’C1.\  was  simply  a  second  generation  or  second  versioti  .M  YCI.N  progratn 
developed  to  provide  explanations  of  problem-solving  strategies.  The  major  contri¬ 
bution  here  was  the  separation  of  control  knowledge  from  domain  knowledge  and 
the  concept  of  similar  explanation  processes  at  two  different  levels  of  abstraction 
(the  task  level  and  the  rule  or  domain  level). 

This  chapter  and  the  information  presented  in  Chapter  3  constitute  a  review  of 
the  first  work  done  in  explanation  generation  research  and  development.  Much  of 
what  has  been  discussed  is  still  available  in  expert  system  EFs  today,  even  though 
the  ideas  and  concepts  are  ten  to  fifteen  years  old.  However,  more  recent  avenues 
of  EF  research  present  some  new  and  different  ideas  and  are  the  focus  of  the  next 
several  chapters. 


Chapter  5 

Explanation  Sz  Explicit 
Development  Models 

5.1  Overview 

In  Chapter  3  we  noted  that  a  M.  I.  T.  article  by  Gorry  provided  the  initial  inspiration 
for  the  EF  research  conducted  in  the  MYCIN  family  of  projects.  The  importance 
of  and  need  for  explanation,  therefore,  existed  in  the  minds  of  M.  1.  T.  researchers 
as  well  as  in  the  minds  of  those  at  Stanford.  This  chapter  looks  at  some  of  the  work 
done  in  explanation  generation  at  M.  1.  T.  Specifically,  it  looks  at  the  work  done  by 
William  Svvartout  over  a  ten  to  twelve  year  period  (late  1970s  to  present)  involving 
three  related  expert  systems;  A  Digitalis  Therapy  Advisor  With  Explanations  [34], 
XPLAIN  [35],  and  Explainable  Expert  Systems  (EES)  [24,32].  By  examining  each 
of  these  in  detail  we  will  recognize  the  important  enhancements  and  extensions  to 
explanation  generation  this  total  research  and  development  effort  has  contributed. 

5.2  A  Digitalis  Therapy  Advisor  With 
Explanations 

5.2.1  Background 

The  Digitalis  Therapy  Advisor  With  Explanations  project  (which  we  will  refer  to 
simply  as  Digitalis)  ^as  begun  sometime  in  1977  for  the  purpose  of  providing  advice 
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to  pliysiciaiis  regarding  digitalis  therapy.  Therefore,  this  system  was  a  nu'dical  con¬ 
sultation  system  similar  to  M\CL\.  Digitalis  w'as  based  on  a  prevdously  developed 
digitalis  advisory  system  that  had  been  done  at  M.  I.  T.  by  Pauker,  Silverman,  and 
Gorry.  Swartout's  work  was  concerned  with  providing  an  EF  for  this  system  (as  its 
name  indicates). 

5.2.2  Problems  Addressed 

There  were  three  main  problems  or  limitations  in  e.xisting  EFs  that  motivated 
Swartout’s  work  on  Digitalis.  Two  of  these  were  identified  from  the  MYCI.N  system: 
one  being  revision  and  the  other  being  the  limited  information  content  capability 
of  an  individual  rule.  Tlie  third  problem  comes  from  the  Software  Engineering 
area.  Swartout  recognized  that  an  e.xpianation  system  could  be  used  to  provide 
self-documenting  programs  and,  thus,  help  alleviate  the  well  known  documentation 
problems  that  e.xist  in  software  development  and  maintenance. 

5.2.3  A  Procedural  Approach 

Based  on  Davis’  work  with  meta-level  knowledge  and  rule  based  systems  [12],  in 
which  he  recognized  that  physicians  tend  to  think  of  sequences  of  operations  in  pro¬ 
cedural  terms,  Swartout  chose  procedures  rather  than  rules  as  his  primitive  knowl¬ 
edge  representation  structure.  Using  the  top-down  refinement  approach  of  standard 
structured  programming^  Swartout  developed  Digitalis  as  a  hierarchy  of  procedures. 
This  hierarchy  was  broken  into  levels  of  abstraction,  with  higher  level  procedures 
representing  higher  level  goals  and  lower  level  procedures  representing  lower  level 
subgoals.  As  will  be  seen  shortly,  developing  this  hierarchy  of  procedures  provided 
.some  distinct  advantages.  Additionally,  Swartout  included  the  now  familiar  execu¬ 
tion  trace/history  tree  in  the  design  of  Digitalis. 


5.2.4  Contributions/Enhancements 

The  first  major  contribution  of  Swartout’s  approach  was  that  it  more  closely  modeled 
the  structure  of  a  human  expert's  solution  process.  In  fact.  Digitalis’s  success  in 
providing  enhanced  explanations  was  fundamentally  based  on  this  assumption.  If 
the  model  of  the  program's  solution  structure  was  the  same  as  (or  close  to)  that 
of  the  human  expert  then  it  was  logical  to  assume  that  the  explanations  generated 
from  such  a  model  would  be  more  understandable  by  the  user. 

The  second  major  contribution  was  that  the  levels  of  abstraction  in  the  hierar¬ 
chy  of  procedures  provide  a  natural  (implicit)  way  of  providing  varying  degrees  of 
explanation  detail  to  the  user.  Swartout  provided  the  capability  to  explain  every 
procedure  in  the  system.  In  addition,  higher  level  procedures  could  summarize  all 
of  the  calls  it  made  to  lower  level  procedures.  Thus,  the  first  request  for  explanation 
a  user  made  yielded  the  higher  level  summary.  For  each  subsequent  request  by  the 
user,  the  next  lower  level  in  the  hierarchy  vvas  explained.  This  process  contiiuied 
until  the  user  had  received  the  degree  of  explanation  detail  desired. 

The  third  enhancement  of  Digitalis  addressed  the  revision  problem.  Remember 
that  when  MYCIN  was  ask  to  recompute  its  answer  based  on  different  input  infor¬ 
mation,  it  had  to  recompute  the  entire  consultation  session.  Swartout  overcame  this 
inefficiency  by  developing  a  smarter  interpreter  that  only  recomputed  the  steps  ef¬ 
fected  by  the  changed  input.  Thus,  performance  efficiency  increased  and  the  amount 
of  redundant  information  provided  in  the  explanations  decreased. 

The  final  enhancement  we  will  discuss  involves  Digitalis’s  ability  to  explain  how 
program  variables  were  set  and  used.  Because  Digitalis’s  knowledge  base  was  com¬ 
pletely  cross-referenced.  Swartout  developed  routines  that  took  advantage  of  this 
cross-referencing  and  provided  these  additional  explanations. 
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5.2.5  Limitations 

The  first  linritation  was  based  on  the  assumption  identified  earlier  —  that  the  pro¬ 
gram's  structure  closely  matched  the  human  expert's  structure  for  solving  the  prob¬ 
lem.  If  this  wasn't  true,  Digitalis  couldn’t  provide  very  useful  explanations.  There¬ 
fore,  a  great  responsibility  was  placed  on  the  system  designer  to  insure  the  above 
assumption  was  met. 

The  second  limitation  results  from  using  the  hierarchy  of  procedures.  Digitalis 
could  only  provide  a  limited  number  of  explanations.  This  number  was  directly 
related  to  tlie  number  of  levels  of  abstraction  in  the  hierarchy  and  was  fixed  once 
the  program  was  written.  If  the  explanation  at  one  level  was  too  general  and  at 
another  level  was  too  detailed,  there  was  no  way  to  produce  intermediate  levels  of 
explanation  if  that  abstraction  level  did  not  already  exist. 

.Another  limitation  of  this  system  was  its  inability  to  tailor  its  explanations  to 
its  user.  Digitalis  did  not  attempt  to  obtain  a  specific  model  of  each  individual 
user.  Explanations  were  provided  in  one  format  whether  the  user  was  a  layman  or 
a  doctor,  a  novice  or  an  expert.  In  addition,  because  an  English  parser  was  never 
developed,  requests  for  explanations  had  to  be  entered  in  the  form  of  LISP  function 
calls. 

Finally,  Digitalis  couldn’t  adequately  justify  its  actions.  It  didn’t  have  the  knowl¬ 
edge  it  needed  explicitly  encoded  and  available  for  explanation. 

5.2.6  Conclusion 

In  analyzing  this  system  from  the  standpoint  of  our  Functional  Framework  we  find 
that  Digitalis  provides  the  same  Function  1,  Type  1  explanations  as  MYCIN  did 
and  used  the  same  mechanism  for  doing  so  —  the  execution  trace/history  tree.  Its 
Type  2  explanation  capabilities  were  found  in  its  use  of  the  cross-reference  index  and 


in  its  ability  to  explain  each  procedure  in  its  code.  Digitalis  could  provide  limited 
justifications  for  its  reasoning  but  still  fell  considerably  short  of  the  full  intent  of 
Type  2  explanations.  .As  with  MYCTN,  Digitalis  didn't  provide  any  Function  1.  Type 
3  explanations  at  all.  Digitalis's  Function  2  capabilities  were  implicitly  contained 
in  the  levels  of  abstraction  of  its  hierarchical  structure.  Digitalis  also  provided 
its  explanations  in  both  algorithmic  form  and  in  English,  a  Function  3  capability. 
However,  its  recjuirement  for  input  to  be  in  the  form  of  LISP  functions  was  a  definite 
drawback. 

This  first  EF  by  Swartout  made  several  improvements  over  MYCIX's  original  FF 
and  was  ultimately  successful  in  providing  solutions  to  the  problems  that  motivated 
its  development.  However,  its  significant  importance  is  more  as  a  stepping  stone  for 
further  research  (similar  to  MYCIN)  than  as  a  functional  EF. 

5.3  XPLAIN 

5.3.1  Background 

The  XPL.AIN  system  [35j  was  developed  several  years  after  Digitalis  and  was  a  direct 
descendent  of  this  system.  Its  application  domain  (digitalis  therapy)  and  functional 
purpose  (providing  physicians  with  advice  for  administering  digitalis  therapy)  were 
the  same  and  it  used  many  of  the  original  Digitalis  structures  and  concepts. 

5.3.2  Problems  Addressed 

.Swartout  was  convinced  that  the  next  important  step  in  EF  development  was  for  a 
system  to  not  only  explain  what  it  did  but  to  explain  why  it  did  what  it  did 
—  to  justify  its  reasoning  process.  He  felt  this  justification  was  important  because 
it  could  reveal  whether  or  not  a  system  was  based  on  sound  principles  or  was  being 
pushed  beyond  the  bounds  of  its  expertise.  Realizing  that  the  knowledge  needed  to 
provide  this  justification  was  the  knowledge  required  by  the  programmer  to  create 


the  program,  but  not  required  for  successful  performance  of  the  program  once  it  was 
written  (our  deep  knowledge  again),  Swartout  searched  for  ways  of  capturing  and 
explicitly  encoding  this  knowledge.  XPLAIN  was  developed  as  a  solution  to  this 
problem. 

5.3.3  An  Explicit  Development  Approach 

.\gain.  the  motivation  behind  XPLAIN’s  development  was  Swartout's  desire  to  dis¬ 
cover  some  way  of  capturing  the  programmer’s  knowledge  and  decisions  that  were 
used  to  create  the  program,  to  capture  this  deep  knowledge.  What  Swartout  came 
up  with  is  really  quite  interesting.  He  decided  to  develop  an  Automatic  Program 
H’n'fer  that  would  use  several  different  sources  of  knowledge  to  create  a  performance 
program  of  the  system,  keeping  a  record  of  its  decisions  in  the  process.  There  vvere 
five  basic  parts  to  the  system  he  designed  to  do  this: 

1.  Domain  Model:  The  domain  model  represents  the  facts  of  the  domain.  It  is 
a  model  of  the  causal  relationships  that  are  important  in  digitalis  therapy. 
These  facts  correspond  to  the  sort  of  facts  a  medical  student  would  learn 
during  the  first  two  years  of  medical  school.  These  facts  tell  what  happens 
in  the  domain  but  do  not  tell  what  behavior  should  be  used  to  achieve  the 
goal  of  administering  digitalis. 

2.  Domain  Principles:  The  domain  principles  tell  how  something  is  to  be  done 
and  can  be  thought  of  as  abstract  procedural  schemas.  These  schemas  are 
filled  with  facts  from  the  domain  model  to  produce  specific  instantiations 
of  procedures.  Domain  principles  are  therefore  comprised  of  variables  and 
constants.  There  are  four  parts  that  make  up  a  domain  principle; 

(a)  Goal:  The  goal  of  a  principle  indicates  precisely  what  this  principle  can 
accomplish.  Domain  principles  are  arranged  in  a  hierarchy  based  on  the 
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specificity  of  these  goals. 

(b)  Domain  Rationale:  The  rationale  of  a  domain  principle  consists  of  a 
pattern  that  is  matched  against  the  domain  model  and  is  used  to  provide 
additional  information  for  achieving  a  prin*  iole's  goal. 

(c)  Prototype  Method:  The  prototype  method  is  an  abstract  method  for  ac¬ 
complishing  a  domain  principle’s  goal.  It  is  instantiated  each  time  the 
domain  rationale  matches  the  domain  model.  When  this  happens  a  new 
structure  is  created  with  the  variables  in  the  prototype  method  being 
replaced  by  their  matching  counter-parts  from  the  domain  model. 

(d)  Constraints:  .\n  optional  sei  of  constraints  may  be  attached  to  a  domain 
principle  and  are  used  to  identify  specific  events  or  criteria  that  must  be 
met  before  the  principle  can  be  used. 

3.  English  Generator.  The  English  generator,  which  provides  the  English-like 
explanations  presented  to  the  user,  consists  of  two  parts. 

(a)  Phrase  Generator.  The  phrase  generator  constructs  English-like  phrases 
directly  from  the  knowledge  base  and  is  the  primary  work  horse  of  this 
part  of  the  system. 

(b)  Answer  Generators:  Answer  generators  are  responsible  for  selecting  the 
different  parts  of  the  knowledge  representation  structures  that  are  to 
be  translated  into  English  by  the  phrase  generator.  These  routines  are 
responsible  for  determining  the  level  of  detail  of  an  explanation.  This 
is  done  using  viewpoints,  which  are  indicators  attached  to  t'  e  steps  in 
the  prototype  methods  and  identify  who  each  particular  step  should  be 
explained  to  (i.  e.  novice,  knowledge  er  ^ineer,  domain  expert,  everyone, 
etc.  ). 


N  OTE;  The  phrase  generator  and  the  knowledge  representation  language 
used  in  this  system  were  not  developed  by  Swartout.  They  were  con¬ 
tained  in  a  system  called  XLMS  (experimental  Linguistic  Memory  Sys¬ 
tem)  which  had  been  previously  developed  at  M.  I.  T. 

4.  Automatic  Program  IVt'-iter.  This  is  the  program  that  uses  the  domain  model 
and  the  domain  principles  to  create  the  performance  program  for  a  particular 
digitalis  advisory  session.  The  user  of  the  system  actually  interfaces  with  the 
performance  program  during  e.xCwUtion. 

5.  Refinement  Structure:  The  refinement  structure  is  the  most  important  part  of 
Swartout's  system  because  it  contains  the  deep  knowledge  Swartout  set  out 
to  capture.  The  refinement  structure  is  the  trace  left  behind  by  the  automatic 
program  writer  showing  how  the  writer  developed  the  current  digitalis  advisor 
performance  program.  This  structure  is  actually  a  tree  of  goals,  each  being  a 
refinement  of  the  one  above  it.  At  the  lowest  level  of  this  tree  (its  leaves)  are 
the  primitive  operations  that  the  performance  program  actually  executes. 

The  explanations  XPLAIN  produces  are  generated  using  the  refinement  structure, 
an  execution  trace  created  by  the  performance  program,  the  domain  model,  the 
domain  principles,  and  the  English  generator.  While  details  of  how  this  is  done 
exceeds  the  scope  of  this  paper  (the  interested  reader  is  referred  to  [35]),  the  impor¬ 
tant  points  to  note  are  the  development  of  additional  types  of  knowledge  structures 
(than  seen  in  previous  systems)  and  the  creation  of  an  interesting  way  of  capturing 
the  different  types  of  knowledge  that  go  in  these  structures. 

5.3.4  Contributions 

The  most  important  contribution  of  Swartout’s  work  in  XPL.A.IN  is  the  expan¬ 
sion  of  EE  capabilities  to  another  level  of  detail.  The  previous  systems  concerned 


tlu'ius<>lv('s  with  explaining  the  level  of  detail  of  how  these  systems  performed  their 
reasoning  in  arriving  at  a  decision  or  answer.  XPL.A.IN's  ability  to  justify  the  use  of 
this  reasoning  process  moves  into  another  (higher)  level.  .-Xs  will  be  discussed  more 
explicitly  in  the  next  chapter,  providing  this  second  level  of  explanation  is  an  impor¬ 
tant  step  in  expanding  the  range  of  problems  ESs  can  be  used  to  solve.  Many  people 
believe  that  if  ESs  are  ever  going  to  be  used  to  solve  really  significant  problems 
they  must  be  able  to  produce  high  level  explanations  of  their  actions.  Swartout's 
work  in  XPL.AIN  has  taken  a  major  step  in  this  direction. 

-Xnofher  contribution  of  XPL.AIN  is  the  establishment  of  a  domain-independent 
set  ot  tools  tor  generating  explanations.  The  only  changes  that  would  have  to  be 
made  to  this  system  in  order  to  re-tool  it  for  a  different  application  domain  are  the 
domain  model  and  the  domain  principles.  Everything  else  (the  automatic  program 
writer,  the  English  generator,  etc.  )  could  remain  unchanged  and  the  resulting 
explanations  should  be  as  good  as  those  in  the  original  system.  While  there  was 
nothing  in  the  literature  to  indicate  this  was  done,  it  was  definitely  mentioned  as  a 
possibility. 

One  final  contribution  of  the  work  on  XPL.AIN  is  the  increased  thought  and 
consideration  that  must  be  given  to  the  performance  program  (on  the  part  of  its 
designers/developers)  in  order  to  make  this  system  work.  While  this  may  initially 
be  seen  as  a  complicating  factor  and  therefore  a  limitation  versus  an  advantage. 
Swartout  argues  that  it  is  a  definite  advantage  because  this  increased  thought  process 
produces  a  much  better  understanding  of  the  problem  to  be  solved.  This,  in  turn, 
helps  provide  more  efficient  solutions,  eliminates  many  of  the  more  subtle  errors 
and.  in  short,  produces  a  better  solution  to  the  problem. 


5.3.5  Limitations 


XPLAI.X  also  has  its  liniitalioiis.  The  lirst  of  those  is  that  the  automatic  program 
writer  was  limited  to  a  goal/subgoal  rertnemeiit  strategy.  If  a  domain  principle  could 
not  be  found  to  refine  a  certain  goal,  the  system  could  not  progress  any  further.  It 
did  not  have  the  ability  to  re-evaluate  the  troublesome  goal  and  attempt  to  achieve 
it  using  some  other  strategy. 

.-\nother  limitation  was  that  XPL.-MN  could  only  provide  a  small  s('t  of  different 
types  of  explanations.  This  was  because  the  different  types  of  explanation  were 
produced  by  fixed  procf'dures  that  were  hardcoded  into  the  system.  .Xo  mechanism 
for  adding  more  of  these  procedures  vvas  available. 

5.3.6  Conclusion 

The  de.sire  to  provide  a  justification  mechanism  in  an  EF  motivated  the  research 
and  development  of  this  new  e.xpansion  into  another  level  of  explanation  generation. 
XPL.ALX  was  successful  in  providing  a  solution  to  this  justification  problem.  In 
analyzing  it  from  our  Functional  Framework  perspective  of  Chapter  2  we  notice 
several  improvements. 

Function  1.  Type  I  explanations  are  still  provided  using  the  execution  trace/his¬ 
tory  trw  structure  developed  in  the  original  MYCIN  project.  However,  the  refine¬ 
ment  structure  produced  by  the  automatic  program  writer  provides  a  mechanism 
for  providing  Type  2  explanations.  It  is  important  to  note  that  while  this  paper  has 
given  credit  to  previous  systems  for  providing  some  Type  2  explanation  capabilities, 
with  respect  to  the  full  definition  Chandrasekaran  [S,9]  gives  for  this  type  of  exjda- 
nation.  .XF^L.AIX  is  the  first  system  to  provide  such  a  capability.  .As  for  Function  1. 
lype  .3  explanations,  XPL.AIN  does  not  have  the  capability  to  provide  them. 

In  looking  at  its  Function  2  capabilities  we  find  that  XPL.AIN  has  expanded  on 


this  area  iisiiitr  its  answer  generators  anti  the  \  iewi)Oints  altaehed  t'j  the  dith'rent 
steps  in  the  prototype  methods  of  the  domain  princi[)les.  If  the  user  is  an  expert,  all 
\  itwvpuints  identihed  as  applying  to  an  expert  are  recognized  and  their  corresponding 
steps  are  explained.  Likewise  for  a  novice  or  other  category  of  user. 

.\PL.\1.\  also  erdiances  the  Function  '■]  capabilities  seen  so  far.  dhe  English 
generator  it  uses  is  a  nurch  more  elaborate  system  than  the  template  mechanism 
used  in  M\'(.'L\'  or  the  reliance  on  an  English-like  implementation  language  (as  in 
the  original  Digitalis  system). 

5.4  The  EES  (Explainable  Expert  Systems) 
Approach 

5.4.1  Background 

EES  [24.32]  is  a  direct  extension  of  the  work  done  on  .\PL.\1N.  The  motivation  for 
this  continuation  effort  is  best  described  by  the  following,  taken  horn  an  article  by 
.Veches.  Swartout.  and  Moore. 

■■  The  primary  goal  of  the  EE.S  project  is  to  provide  a  framework  that 
will  facilitate  construction  of  expert  systems  according  to  a  paradigm 
of  separate  models  and  recorded  developments.  This  reciuires  pursuing 
the  lessons  cjf  the  .XPL.-\I.V'  system  by  extending  the  forms  of  knowledge 
known,  extending  the  kinds  of  development  recorded,  and  extending  the 
benefits  beyond  explanation  to  development  and  maintenance."  [24. 
page  1340] 

5.4.2  Problems  Addressed 

EES  addresses  the  limitations  identified  in  the  proceeding  section  on  .XPL.\IN.  How¬ 
ever.  as  can  be  seen  from  the  quote  just  presented,  this  was  not  the  driving  lactor 
behind  EE.S.  I  he  real  problem  EES  addresses  is  the  logical  extension  of  expanding 
a  concejit  or  technique  initially  developed  in  a  constrained  environment  into  a  more 
geni'ral.  robust  one.  Often  times  this  expansion  identifies  completely  different  ap¬ 
plication  areas  where  the  concept  or  techni<me  can  be  used,  as  well  as  expanding 


the  iiiii  u  a|)[)licat ion  an'a.  Ttiis  is  tnio  with  KES.  I'he  work  done  on  this  ^y^tciii 
not  only  henelits  Eh  research  and  devt-lopincnit  but  also  provides  assistance  to  t  he 
Software  Engineering  areas  ot  software  development  and  maintenance. 

5.4.3  Enhancements 

We  will  leok  at  the  enhancements  EES  makes  to  XPL.MN  based  on  the  three  areas 
irlentihed  in  the  cpiote  above:  extending  the  forms  of  knowledge,  extending  the  kinds 
of  dev(dopment  recorded,  and  extending  the  benefits  beyond  explanation. 

In  addition  to  XF^LAIN's  domain  model  and  domain  principles,  live  other  forms 
id  knowledge  are  used  in  EES. 

1.  Tradeoffs:  Iradeoffs  are  associated  with  domain  principles  and  are  used 
indicate  the  beneficial  and  harmful  effects  of  selecting  a  particular  strategy 
(method)  for  achieving  a  goal. 

2.  Prefe rences:  Preferences  are  associated  with  the  goals  of  do/nain  principles 
and  make  up  a  set  of  priorities  for  strategy  selection  based  on  the  identified 
tradeoffs. 

d.  Tenninology:  Terminology  is  a  new  name  for  what  was  identified  in  XPL.MN 
as  a  domain  principle's  prototype  method.  In  EES  these  prototype  methods 
were  broken  out  as  a  separate  knowledge  type  so  they  could  be  shared  across 
different  domain  principles. 

1.  Integration  knowledge:  Integration  knowledge  is  used  to  resolve  potential  con¬ 
flicts  among  different  knowledge  sources. 

■').  Optunization  Knondedge:  Optimization  knowledge  represents  ways  of  etfi- 
ciently  controlling  execution  of  the  performance  system. 
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With  I'f'spect  to  extending  tlie  kinds  of  development  recorded.  EKS  does  this  bv 
redesigning  the  automatic  program  writer  into  two  parts.  The  first  part  uses  all 
of  the  ditferent  knowledge  types  (except  the  optimization  knowledge)  to  produce 
the  initial  performance  program  just  as  XPLAIN  did.  The  refinement  structure 
that  results,  however,  has  been  greatly  improved  because  more  and  different  types 
of  knowledge  were  used  to  generate  it  and  because  the  automatic  program  writer 
had  the  capability  to  reformulate  a  goal  automatically  if  no  domain  principle  could 
be  found  to  refine  it.  The  second  part  of  the  automatic  program  writer  (the  new 
part  with  re.spect  to  XPL.MX)  modifies  the  initial  refinement  structure  bv  running  it 
through  an  efficiency  optimizer  (which  uses  the  optimization  knowledge).  Therefore, 
the  extended  kinds  of  development  recorded  in  EES's  refinement  structure  are  the 
result  of  more  knowledge  types,  automatic  goal  reformulation,  and  optimization. 

The  extension  of  benefits  beyond  expl'  nation  was  a  natural  result  of  the  other 
two  enhancements  just  identified.  EES  has  access  to  many  different  kinds  of  knowl¬ 
edge  and  the  ability  to  explain  each  of  these  types.  Therefore,  if  one  were  to  look 
at  EES  through  the  eyes  of  a  software  engineer,  one  would  see  the  beginnings  of  a 
self-documenting  system.  .As  has  been  well  established,  documentation  is  a  very  se¬ 
rious  problem  with  any  large  software  program,  especially  after  it  has  been  changed 
and  revised  (mruntained)  several  times.  .A  system  with  an  EES  explanation  capa¬ 
bility  would  have  its  own  self-contained  documentation  system.  The  new  program 
maintainer  could  sit  down  at  a  terminal  and  ask  questions  to  determine  how  the 
code  works,  why  certain  things  were  done  certain  ways,  why  or  how  specific  pieces 
(jf  data  relate  to  other  pieces  of  data,  etc. 

5.4-4  Limitations 

I  he  biggest  limitation  or  area  for  future  work  in  EES.  as  identified  by  its  architects, 
is  in  the  area  of  the  user  interface.  Because  EES  provides  so  much  EE  capability. 


the  easier  it  is  tor  someone  to  use,  the  more  use  it  will  gel.  Currently,  it  isn't  easy 
to  use. 

5.4.5  Conclusion 

EES  has  built  on  the  lessons  learned  from  .XPLAIN.  VVe  have  discussed  how  it  did 
this  with  respect  to  the  quoted  statement  at  the  beginning  of  this  section.  With 
respect  to  our  old  friend  the  Functional  Framework.  EES  does  not  provide  any 
startling  new  capabilities,  but  that  wasn't  it's  purpose.  It's  basic  purpose  was  to 
e.xtend  a  technology  developed  in  a  very  specific  application  domain  into  a  general 
framework  for  expert  system  construction.  How  well  EES  has  done  this  has  yet  to 
be  determined. 

5.5  Summary 

This  chapter  has  examined  the  explanation  generation  work  done  at  M.  1.  T.  over 
the  past  ten  to  twelve  years.  .As  with  MYCIN  and  the  family  of  related  systems 
resulting  from  it,  the  work  discussed  in  this  chapter  can  also  be  viewed  as  a  family 
of  related  systems. 

The  Digitalis  Therapy  .Advisor  With  Explanations  was  the  first  system  developed 
in  tilts  family.  Representing  knowledge  as  procedures  instead  of  rules,  placing  these 
procedures  into  a  hierarchy  of  abstraction  levels,  and  providing  the  capability  to 
explain  every  procedure  in  the  system  were  the  major  contributions  of  this  system. 

XPL.AIN  was  the  second  system  developed  in  this  family  and  was  primarily 
concerned  with  providing  justification  type  explanations.  The  automatic  program 
writer  and  resulting  refinement  structure  used  to  provide  this  type  of  explanation  was 
a  major  contribution  to  the  field  of  explanation  generation  research.  In  addition, 
in  providing  these  justifications,  a  higher  level  of  explanation  was  achieved,  thus 
(opening  the  door  for  a  wider,  more  significant  range  of  problems  to  be  addressed  by 


EES.  the  last  system  developed  in  this  family,  provided  the  logical  e.xpansion 
and  impro\ement  of  the  XPL.4L\'  system  into  a  more  generic,  i.lomain-independent 
ES  development  tool. 

fhe  work  done  with  respect  to  this  family  of  ESs  is  an  ongoing  effort.  EES  is 
a  very  current  system  providing  state-of-the-art  explanation  capabilities.  Interest¬ 
ingly.  it  is  so  current  that  little  has  been  written  about  it  in  the  literature.  However, 
the  significance  of  its  underlying  system  (XPL.-\IN)  is  well  documented. 


Chapter  6 


Generic  Tasks  &c  Explanation 

6.1  Overview 

The  work  we  are  going  to  examine  in  this  chapter  is  a  continuing  effort  being  con¬ 
ducted  at  the  AI  Research  Laboratory  at  Ohio  State  L'niversity.  It  started  in  the 
late  1970s  under  the  direction  and  leadership  of  B.  Chandrasekaran.  As  a  result  of 
their  early  work  in  medical  diagnostic  knowledge-based  systems  (work  stimulated 
by  the  MYCIN  project)  the  beginnings  of  a  general  framework  for  developing  ESs 
began  to  be  identified  by  Chandrasekamii’s  group  of  researchers.  .As  their  work  in 
this  area  continued,  it  became  evident  that  the  development  of  this  framework  could 
unify  three  major  areas  in  ES  construction;  the  problem-solving  process,  deep  cogni¬ 
tive  models,  and  explanation.  Further  research  and  development  of  this  framework 
continues  to  be  a  primary  focus  of  Chandrasekaran  (and  those  associated  with  him) 
and  is  now  known  as  the  generic  task  approach  to  knowledge  acquisition  and  ES 
construction. 

This  chapter  will  examine  this  concept  a  little  differently  than  has  been  done  in 
previous  chapters.  No  one  particular  ES  (or  family  ot  ESs)  will  be  discussed.  Rather, 
we  will  first  present  an  overview  or  summary  of  the  entire  generic  task  concept  and 
will  then  identify  the  benefits  it  provides  with  respect  to  explanation  generation.  It 
is  important  to  note  that  different  experimental  ESs  have  been  developed  a.s  part  of 
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this  research  and  development  effort.  In  addition,  the  documentation  of  this  work 
is  contained  in  numerous  articles  (  [4,6,7,9,21,8,23,29]  to  identify  a  few),  with  the 
information  presented  in  this  chapter  being  taken  from  [6,9,8].  The  other  references 
are  included  for  those  interested  in  more  detailed  discussions  of  particular  aspects 
of  this  overall  concept. 

6.2  Problem(s)  Addressed 

The  primary  problem  that  motivated  this  research  effort 's  one  that  has  been  hinted 
at  previously  in  Clancy's  work  on  NEOMYCIN  and  Swartout's  work  on  .XPL.AI.N 
and  EES  but  not  mentioned  or  identihed  explicitly.  Chandrasekaran  et  al.  felt  that 
ESs  needed  to  explain  themselves  at  a  higher  level  (the  architectural  level)  in  a 
manner  appropriate  to  the  problem  solving  task  being  performed.  However,  they 
recognized  that  the  current  approaches  to  know  ledge- based  system  construction  were 
being  conducted  at  too  low  of  a  level  (i.  e.  the  rule  level)  and  that  this  made  it  difficult 
to  provide  high-level  explanations.  Due  to  the  implementation  languages  available, 
system  designers  had  to  transform  problems  into  these  low  level  implementation 
languages  and  then  turn  around  and  provide  explanations  that  required  translating 
these  low  level  representations  back  to  the  problem  level.  Therefore,  the  desire  to 
build  knowledge-based  systems  that  contained  basic  explanation  constructs  at  the 
appropriate  levels  of  abstraction  was  a  big  motivator. 

6.3  The  Generic  Task  Framework 

The  basic  assumption  underlying  this  framework  (and  identified  during  the  earlv 
medical  diagnostic  research)  was  that  there  are  different  types  of  problem-solving 
processes  and  that  there  are  different  types  of  knowledge  and  control  structures 
used  within  each  of  these  different  problem-solving  types.  For  example,  diagnostic 
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reasoning  is  one  type  of  problem-solving  application  and  has  its  own  specific  knowl¬ 
edge  types  and  control  structures.  Theory  formation,  design,  and  perception  are 
other  problem-solving  application  areas  whose  solutions  have  been  attempted  by 
ESs.  Each  of  these  also  has  its  own  specific  knowledge  types  and  control  strategies. 
In  addition,  it  is  also  assumed  that,  for  the  most  p^rt.  the  knowledge  types  and 
control  regimes  are  different  for  each  type  of  problem-solving  area. 

Based  on  this  assumption  (or  these  assumptions)  the  basic  concept  that  was 
lormulated  was  to  represent  the  appropriate  knowledge  and  control  information  for 
each  different  problem-solving  task  using  a  vocabulary  appropriate  for  that  partic¬ 
ular  task,  rids  was  to  be  done  by  first  identifying  the  different  tasks,  second  by- 
studying  and  analviiing  the  knowledge  and  control  structures  used  by  each,  and 
then  by  constructing  a  design  language  for  each  task  that  provided  the  knowledge 
structures  and  control  strategies  specific  to  that  task.  By  doing  this,  the  ability  to 
program  at  a  higher,  more  appropriate  level  of  abstraction  could  be  conducted  (the 
same  basic  reasoning  that  motivated  the  development  of  the  high  level  programming 
languages  used  in  structured  programming). 

Use  of  this  concept  has  identified  six  generic  tasks,  each  with  its  own  design 
language.  A  brief  description  of  each  is  now  presented. 

1.  Hierarchical  Classification:  This  task  is  very  applicable  in  diagnostic  type 
applications  a.s  evidenced  by  our  discussions  of  other  systems  that  used  a 
goal/subgoal  hierarchy.  It  is  based  on  the  construction  of  a  classification  hier¬ 
archy  and  uses  an  establish  and  refine  strategy  (similar  to  the  one  described 
in  EES)  to  control  its  processing.  Each  node  in  the  hierarchy,  starting  from 
the  top,  tries  to  match  its  establishment  conditions  against  data  in  the  knowl¬ 
edge  base.  If  successful,  the  process  repeats  using  the  successors  of  this  node. 
If  unsuccessful,  the  node  and  all  of  its  successors  are  rejected. 


2.  Design  By  Plan  Selection  And  Refinement:  This  task  is  used  to  design  some 
object  according  to  a  set  of  specifications.  Specialists  (which  are  the  software 
representations  of  components  of  the  object  to  be  designed)  are  arranged  in 
a  liierarchy  that  mirrors  the  structure  of  the  actual  object,  with  each  special¬ 
ist  containing  plans  the  system  can  use  to  determine  when  and  if  to  use  it. 
Using  a  top  down  control  strategy,  the  plan  of  a  specialist  is  chosen  based  on 
some  specification.  The  design  parts  of  the  specialist  are  then  instantiated  and 
another  specialist  is  called  to  fill  in  some  other  design  part(s).  This  process 
is  done  recursively  until  the  design  is  complete.  If  a  particular  design  part 
fails  to  get  instantiated,  control  moves  back  up  the  hierarchy  to  allow  higher 
level  specialists  to  change  their  plans  and  then  the  downward  control  is  re¬ 
sumed.  This  provides  a  second  chance  mechanism  for  instantiating  the  part 
that  initially  failed. 

3.  State  Abstraction:  This  task  is  used  to  e.xamine  the  effects  of  applying  changes 
to  some  type  of  system  and  is  quite  similar  to  the  design  task  just  e.xplained.  .A 
hierarchy  of  system/subsystem  components  is  constructed.  However,  control 
is  from  the  bottom  up  in  this  task,  not  from  the  top  down. 

4.  Knowledge- Directed  Information  Passing:  This  task  is  structured  as  a  hier¬ 
archy  of  frames  and  is  used  to  obtain  attribute  values  of  related  data.  This 
is  accomplished  by  using  actual  values  for  the  attribute  (if  they  are  known), 
using  frame  inheritance  to  infer  their  values  from  parents  or  children,  or  by 
executing  demons  that  query  other  frames  in  the  hierarchy  for  the  desired 
information. 

0.  Hypothesis  Matching:  This  task  is  used  to  match  a  concept,  hypothesis,  spe¬ 
cialist,  or  whatever  name  a  particular  entity  may  have,  against  relevant  data 


in  the  knowledge  base  and  to  determine  the  degree  of  til  for  the  alteniptecl 
match.  The  degree  of  fit  is  an  abstraction  of  the  data  computed  for  use  in 
the  matching  process  to  deal  with  the  uncertainty  so  often  associated  with 
the  data  and  is  represented  in  symbolic  form  (i.  e.  high,  medium,  low,  good, 
bad.  etc.  ).  This  task  is  frequently  used  in  conjunction  with  other  tasks  in  a 
problem-solving  process. 

6.  Abductive  Assembly:  This  task  is  a  different  way  of  performing  the  diagnostic 
process  associated  earlier  with  the  classification  hierarchy.  The  basic  idea  is  to 
build  the  best  hypothesis  possible  that  explains  the  data  using  causal  knowl¬ 
edge  that  relates  the  .set  of  possible  hypotheses  with  the  relative  significance 
of  the  data  items. 

These  six  generic  tasks  do  not  constitute  a  closed  or  complete  set.  i  he  search  for 
additional  tasks  continues.  However,  as  was  stated  earlier,  design  languages  for  each 
of  these  six  tasks  have  been  developed  and  several  experimental  systems  have  been 
built  using  them. 

6.4  Contributions 

There  are  several  contributions  that  have  resulted  from  this  work.  First,  a  formal 
methodology  or  framework  has  been  defined  for  building  ESs  and  producing  better 
explanations.  This  framework  provides  all  three  of  the  Function  1  type  explana¬ 
tions  defined  in  our  Functional  Framework  (this  is  not  surprising,  however,  as  the 
definitions  of  these  types  came  out  of  this  research  effort).  Specifically,  Type  1 
explanations  are  provided  using  the  familiar  e.xecution  trace/history  tree.  Tv[)e  2 
explanations  are  provided  in  the  different  knowledge  types  defined  for  the  specific 
task  being  performed  (similar  to  the  mechanism  described  in  EES).  Type  3  explana¬ 
tions  are  provided  by  the  same  execution  trace  used  to  provide  Type  1  explanations. 


I  his  is  because  the  control  strategy  is  explicitly  represented  in  the  implementation 
language  specifically  designed  for  the  task  being  performed. 

.A  second  contribution,  and  in  many  ways  the  most  important,  is  the  recognition 
that  explanation  can  be  derived  naturally  from  deep  models  and  an  understanding 
of  the  problem-solving  task.  While  this  notion  has  been  hinted  at  in  discussions  of 
pre\ious  work  (specifically  NEOMYCIN  and  EES),  it  has  been  formally  recognized 
and  established  in  this  work  on  generic  tasks. 

Two  other  contributions  have  resulted  from  this  work.  First,  by  providing  a 
tramework  for  producing  high  level  explanations,  the  door  has  been  opened  for  the 
re.search  and  development  of  ESs  capable  of  solving  more  significant,  meaningful 
problems  (further  extension  of  this  same  contribution  identified  in  Chapter  5).  Sec¬ 
ond.  this  framework  provides  a  set  of  generic  tools  for  ES  development. 

6.5  Limitations 

Chandrasekaran  notes  that  while  generic  tasks  are  a  vast  improvement  over  the  low- 
level  implementation  languages,  explanations  can  still  be  provided  at  a  higher  level 
of  abstraction  than  the  task  level.  This  higher  level  is  the  level  of  the  actual  problem¬ 
solving  task.  For  example,  in  medical  diagnosis  this  level  would  be  the  diagnostic 
level  and  would  provide  explanations  on  how  system  actions  and  decisions  met 
diagnostic  goals.  Therefore,  generic  tasks  are  not  the  final  answer. 

6.6  Summary 

The  emphasis  of  this  chapter  has  been  on  explaining  the  conceptual  framework 
developed  at  Ohio  State  for  building  ESs  and  producing  high  level  explanations. 
The  major  contribution  of  this  work  is  the  recognition  that  if  enough  study  and 
analysis  of  a  problem-solving  task  can  be  conducted  and  the  knowledge  types  and 
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control  strategies  used  by  the  task  ideutihed  and  represented,  then  the  language 
built  to  specifically  provide  these  capabilities  will  inherently  provide  the  capability 
to  produce  high  level  explanations. 


Chapter  7 

A  Potpourri  Of  Additional  EF 
Topics 

7.1  Overview 

The  purpose  of  this  chapter  is  to  present  additional  work  being  done  in  explanation 
generation.  The  systems  and  work  described  here  are  independent  of  each  other 
and  of  any  of  the  previously  discussed  systems.  They  are  grouped  together  in  one 
chapter  because  each  is  its  own  individual  system  designed  to  provide  a  very  specific 
capability  versus  the  much  broader  range  of  related  systems  and  work  presented  in 
the  previous  chapters. 

The  first  system  we  will  examine  is  concerned  with  providing  enhanced  Func¬ 
tion  2  capabilities  (from  our  Functional  Framework).  The  second  system  presents 
some  interesting  work  that  has  been  done  in  analyzing  and  identifying  the  infor¬ 
mation  content  of  typical  rules  in  a  rule-based  system.  The  third  and  final  system 
is  concerned  with  identifying  ways  to  provide  enhanced  EFs  to  existing  expert  sys¬ 
tems  in  use  in  the  field  (non-research  or  non-academic  type  ESs).  Interestingly, 
these  last  two  systems  are  related  in  that  they  are  both  concerned  with  providing 
enhanced  explanation  capabilities  to  existing  systems,  though  from  much  different 
perspectives. 
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7.2  BLAH 


7.2.1  Background 

Hie  BLAH  system  [37]  was  developed  by  J.L.  Weiner  at  the  I'niversity  of  Xew 
Hampshire  in  the  early  19S0s.  'Fhis  work  was  conducted  around  the  same  time  as 
l  EIRESIAS  and  The  Digitalis  Therapy  Advisor  and  was  primarily  tocused  on  de¬ 
veloping  ways  to  structure  explanations  so  that  they  were  less  complex  and  easier 
to  understand.  Much  of  the  work  done  in  BL.AH  was  based  on  a  series  of  psycholin- 
guistic  studies  that  analyzed  the  different  ways  humans  explain  decisions,  choices, 
plans,  etc.  to  one  another.  BL.AH  was  then  designed  from  the  frame  of  reference  of 
replacing  one  of  the  two  individuals  involved  in  this  explanation  process. 

7.2.2  Features 

The  BL.-\H  system  was  basically  a  production  rule  system  made  up  of  sets  of  rules 
and  assertions.  .Attached  to  each  assertion  was  a  justification  structure  consisting 
of  three  parts.  The  first  was  the  justification  type  which  corresponded  informally  to 
one  of  several  types  of  justifications  that  people  use  in  explanations.  The  second 
part  was  a  list  of  all  assertions  that  justified  belief  in  the  assertion  in  question.  The 
third  part,  which  was  optional,  was  a  list  of  all  assertions  that  justified  disbelief 
in  the  assertion  in  question.  This  justification  mechanism  played  an  important  part 
in  the  BL.AH  system. 

.Another  interesting  feature  of  the  system  was  the  way  it  segmented  or  partitioned 
its  knowledge  base.  The  first  and  most  important  of  these  (from  an  explanation 
standpoint)  was  the  defining  of  two  different  views:  the  system  view  and  the  user 
new.  Each  view  only  contained  information  that  its  owner  (the  system  or  the 
user)  knew  about.  I  he  knowledge  base  was  also  partitioned  according  to  groups 
of  assertions  that  were  related  to  one  another  in  some  vvay.  Finally,  the  knowledge 


l)ctsc  was  Uri'kcii  iiitu  u'Dihl.--  wliich  iilciit ilied  ilili<T<’nl  sets  ol  pi ciiiix’.^. 


7.2.3  Contributions/ Enhancements 

Reinrnib('ring  that  the  primary  locus  ot  attention  was  to  unconiplicate  comi^lex 
(wplanat ions  so  as  to  make  tliem  easy  to  understand,  several  interesting  ideas  were 
implemented  in  HLAH  to  pro\'i<le  this  capabilitv.  W’e  will  examine  hair  (d  these 
ideas  from  a  conceptual  lev('l. 

1.  Prt.'^itppn.sit ion:  The  idea  !)ehind  presupposition  is  to  limit  what  is  explained 
to  the  user  based  on  what  Ik*  already  knows.  This  was  done  in  BL.AH  lyv 
deleting  from  the  explanation  tree  any  assertions  that  were  contained  in  both 
views  (system's  and  user's)  of  the  knowledge  base. 

'2.  Structure:  I'his  concept  was  concerned  with  structuring  an  explanation  so  that 
it  was  presented  in  ttie  most  understandable  form.  Fliis  was  accomplish'.'d  by 
eitluM'  rearranging  the  explanatioii  tree/reasoning  tree  produced  by  the  rea- 
soidng  component  or  by  breaking  this  tree  up  into  components  and  presenting 
the  explanation  to  the  u.ser  in  increments. 

d.  Altenuitive-s:  When  alternative  explanations  existed  in  the  reasoning  tret', 
rather  than  explain  each  alternative  separately,  the  syste  would  alternate 
between  giving  part  of  the  explanation  for  one  alternative  and  then  jumping 
to  the  other  alternative  and  explaining  the  related  part  of  that  alternative. 
The  purpose  of  this  was  to  group  related  parts  of  alternatives  together  in 
order  to  show  the  relationship  between  them  more  clearly. 

1.  Counterfactuals:  .\  counterfactual  is  an  assumption  »he  system  makes  when 
the  user  warits  the  system  to  show  a  particular  item  .\  and  that  item  is  not 
provable  given  the  current  state  of  the  knowledge  base  at  the  time  of  the  user's 


\\  lu'u  tins  happc'iis.  the  system  assumes  that  the  us<‘r  would  like  to 
kiiow  "irhjj  not  item  X  as  well  as  to  understand  under  what  eircuinst aiices 
item  X  could  be  proved. 

Pro'.  idiuii  these  concepts  in  his  system.  Weiner  created  a  system  that  was  a  leader 
in  providin-j,  Function  2  explanation  capabilities  (referring  back  to  cair  Functional 
Franiew(jrk  attain ). 

7.2.4  Limitations 

Most  ot  tlie  limitations  identified  here  were  ones  that  existed  in  other  FS  expla¬ 
nation  facilities  of  that  time.  Thing.s  like  the  lack  of  a  natural  language  generator, 
uutriendly  user  interface,  and  the  lack  of  a  justification  capability  using  deep  knowl¬ 
edge  were  common  limitations  in  the  early  days  of  explanation  generation. 

Oite  limitation  unicjue  to  BL.AH  was  Weiner's  recognition  of  a  limited  user's  view 
and  the  iitcreased  capabilities  the  system  could  provide  if  this  view  were  increased. 

7.2.5  Conclusion 

BL.MI  was  tlevelo[)ed  in  the  earlier  stages  of  EF  research  and  development  and  was 
instrumetital  in  identifying  several  interesting  ways  to  prot'ide  more  user  friendly 
explanations.  Considerable  study  of  human  explanation  patterns  formed  the  basis 
tor  much  of  the  work  done  on  this  system.  The  enhancements  it  made  to  Function 
■J  type  explanations  are  quite  significant. 

7.3  CLEAR 

7.3.1  Background 

1  lie  ( 'l.lc.AH  system  was  developed  by  Robert  Hubinoll  b]  in  the  early  to  mid  IffSOs 
at  the  I  niversity  tjf  f’ennsylvania.  It  was  designed  as  a  front  (ukI  system  capable 
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of  intf'rfaci:!i>;  to  an  iiKiepen<l«“nlly  developed  KS  and  was  priinarily  concerned  witli 
computing  explanations  automatically  from  the  rules  in  the  ES.  Interestingly,  the 
main  entphasis  of  CLE.XR's  explanations  were  directed  a  little  differently  than  we 
have  seen  so  far.  Wnile  these  ('xplanations  were  directed  at  the  user,  their  purpose 
was  to  explain  the  system's  concepts  and  terms  when  confusion  arose  on  the  part 
of  this  user  about  what  the  system  was  asking  for  or  was  presenting  at  the  time. 
Fherefore.  t'LE.VR's  explanations  were  much  more  concerned  with  the  question  of 
WHAT  is  meant  by  X.'’"  than  with  the  familiar  "WHY  did  X.'"  and/or  "HOW 
did  X'?"  type  questions. 

7.3.2  Methodology 

•As  already  stated.  Rubinolf  was  interested  in  computing  explanations  automatically 
from  the  rules  of  the  knowledge  ba.se.  He  believed  that  rules  could  explain  different 
concepts  based  on  the  type  of  information  encoded  in  them.  This  led  to  an  inten- 
“^ive  study  of  rules  and  their  content  and  resulted  in  the  definition  of  several  types 
of  rules  (particularly  infer circe  rules)  and  several  types  of  concepts  that  could  be 
found  in  different  parts  of  these  rules.  The  key  to  the  CLE.AR  system's  explanation 
capability  was  based  on  identifying  what  type  of  inference  rule  was  being  used  and 
what  concepts  were  encoded  in  its  premise  and  conclusion.  Before  we  look  at  the 
types  of  rules  and  concepts  Rubinolf  identified,  remember  that  the  emphasis  was  on 
explaining  the  system’s  terms  and  concepts,  not  its  control  strategy  or  de¬ 
cision  making  process  or  anything  else.  Therefore,  when  we  say  explanation  in  the 
following  definitions  we  are  referring  to  this  more  restricted  meaning  of  the  word. 

1.  Tupf  s  of  fnffvmcf  Rules 

(a)  caust-tjJtcL  1  hese  rules  are  common  in  medical  diagnosis  and  are  used 
t(.)  deduce  a  cause  from  an  effect  or  vice  versa.  Ehev  identifv  the  causal 
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relationships  in  the  domain  knowledge.  These  rules  can  be  very  useful 
for  explanation  provided  the  user  understands  the  causal  process  behind 
the  connection. 

(b)  paraphrase:  These  are  rules  where  the  conclusion  means  the  same  thing 
as  the  premise.  For  example,  if  .X  is  a  man  and  .X  is  not  married  then 
X  is  a  bachelor.  These  rules  are  very  useful  in  explanation  because  they 
are  based  on  the  meanings  of  terms. 

(c)  problem-action:  These  rules  infer  the  need  for  some  action  based  on  hav¬ 
ing  detected  some  problem.  They  do  not  implement  the  action,  simply 
assert  the  need  tor  it.  These  rules  can  also  be  quite  useful  for  explanation 
provided  the  user  can  see  how  the  action  is  a  response  to  a  problem. 

(d)  matter-of-fact:  These  rules  indicate  a  conclusion  that  is  empirically  true. 
There  is  no  known  underlying  principle  that  explains  why  it  is  true,  it 
jr.st  is.  Generally  these  rules  are  not  very  useful  in  explanation  because 
they  only  provide  miscellaneous  facts. 

(e)  screening  clauses:  Screening  clauses  are  not  really  rules  at  all,  but  instead 
are  clauses  in  the  premise  of  a  rule  used  to  determine  if  the  system  should 
try  and  use  the  rule.  These  clauses,  while  very  important  to  the  execution 
of  the  system,  are  u.seless  from  an  e.xplanation  standpoint  and  may  be 
safely  omitted  from  any  explanation  that  may  be  using  the  rule  because 
it  contains  other  important  information. 

(f)  control:  These  rules  are  nothing  but  screening  clauses  used  in  the  control 
strategy  of  the  system.  As  with  screening  clauses,  they  are  useless  in  the 
explanation  of  a  system’s  terms  and  concepts. 


2.  Types  Of  Concepts  That  Appear  In  A  Rule  Premise 


(a)  tnggtr:  The  rulr  only  succeeds  if  some  attribute  has  a  particular  \'alue. 

(b)  source:  The  rule  depends  on  the  value  of  some  attribute  in  the  concept. 
Therefore  the  concept  is  the  source  of  information  used  by  the  rule. 

(c)  premise  property:  This  is  an  attribute  which  must  have  a  specified  value 
for  the  specified  object(s)  in  the  clause  in  order  for  the  rule  to  succeed. 

(d)  deduced  value:  A  value  which  the  system  deduces  in  the  course  of  proving 
a  premise  clause. 

(e)  chain  value:  A  value  deduced  while  proving  one  premise  that  is  to  be 
used  as  the  source  for  another  premise. 

3.  Types  Oj  Concepts  That  Appear  In  A  Rule  Conclusion 

(a)  result:  The  conclusion  asserts  that  the  concept  is  the  value  of  some  at¬ 
tribute. 

(b)  inferred  property:  An  attribute  whose  value  is  asserted. 

(c)  subject:  The  rule  deduces  something  about  this  concept. 

4.  Types  Of  Coiicepts  That  Appear  In  Both  The  Premise  And  Conclusion  Of  A 
Rule 

{sij  passed-forward  value:  Something  that  appears  as  a  value  in  both  the 
premise  and  conclusion,  something  being  passed  forward  from  conclusion 
to  premise. 

I  hese  definitions  form  the  basis  for  CLEAR’s  explanations.  Surprisingly,  the 
process  that  produces  the  explanations  is  rather  simple.  .After  receiving  a  request 
horn  the  user  for  a  clarification  of  some  term  or  concept  all  rules  are  analyzed  and 
ranked  based  on  their  relevance  to  the  term  or  concept  in  question,  l  ire  ranking  of 


the  rules  is  based  on  the  location  of  the  term  or  concept  in  the  rule.  This  ranking 
process  is  now  listed  in  order  of  importance  from  highest  ranking  to  lowest: 

•  triggers  and  premise  properties 

•  sources  and  inferred  properties 

•  results  and  deduced  values 

•  subjects 

The  highest  ranking  rules  are  then  used  to  generate  the  explanation. 

7.3.3  Contributions 

RubinofF’s  work  in  CLEAR  provides  two  major  contributions  to  EF  research  and 
development.  The  first  is  readily  apparent  and  is  concerned  with  the  increased 
understanding  and  formal  definitions  of  the  types  of  knowledge  contained  in  a  rule. 
The  second  is  a  little  more  subtle,  but  was  identified  in  the  overview  to  this  chapter. 
(.’LEAR  does  not  require  that  special  knowledge  types  or  processing  strategies  be 
added  to  a  system  in  order  to  work.  It  simply  analyzes  the  systtmi’s  existing  rules 
and  uses  the  knowledge  it  finds  there  to  provide  its  clarification  type  explanations. 

7.3.4  Conclusion 

RubinofF’s  work  on  CLE.AR  is  noted  for  its  revelations  concerning  the  information 
content  of  rules.  While  its  particular  implementation  is  dependent  on  the  HPRL 
language  used  to  develop  it,  the  definitions  presented  and  the  methodology  de¬ 
scribed  are  implementation  independent  and  therefore  applica'de  to  a  wide  range  ot 
applications. 
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7.4  JOE 

7.4.1  Background 

JOE  was  developed  by  Michael  Wick  and  James  Slagle  [31]  at  the  University  of 
Minnesota  in  order  to  provide  a  more  unified  and  expressiv'e  explanation  capabil¬ 
ity  for  what  they  identified  as  practice  systems  (non- research  type  ESs  and  ES 
shells  that  are  being  used  commercially  today).  Their  work  was  motivated  by  the 
recognition  that  the  HOW/ WHY  questions  that  MYCI.X  type  systems  can  explain 
from  their  execution  traces/history  trees  are  not  extremely  expressive,  while  the 
current  work  being  done  in  explanation  generation  (XPL.AIN,  Generic  lasks,  etc.  ) 
involves  systems  that  are  too  complicated  and  domain  specific  to  be  integrated  into 
common  use.  .More  specifically,  they  noted  that  the  work  being  done  in  XPL.AIN. 
.N'EOMYCI.X,  and  the  deep  knowledge  and  generic  tasks  at  Ohio  .State  all  required 
the  use  of  supplementary  knowledge  for  their  explanations,  yet  most  practice  sys¬ 
tems  are  not  equipped  to  provide  this  supplementary  knowledge.  Further  more,  they 
noted  that  these  systems  lack  the  equipment  required  to  carry  on  an  interactive  ex- 
p  ration  with  the  user  (natural  language  processors.  English  generators,  etc.  )  and 
are  normally  unable  to  model  the  user’s  knowledge  or  intention. 

7.4.2  A  Journalistic  Approach 

In  searching  for  a  solution  to  this  problem,  Wick  and  Slagle  ventured  into  the  area 
of  journalism.  Discovering  the  four  musts  of  a  newswriter’s  task  to  be  accuracy, 
attribution,  fairness,  and  objectivity,  Wick  and  Slagle  quickly  recognized  the  simi¬ 
larities  that  existed  between  this  discipline  and  the  functionality  of  EEs  on  current 
practice  systems.  Both  involved  presenting  readers/users  with  accurate,  objective, 
noninteractive  accounts  of  events.  This  being  the  case,  Wick  and  Slagle  pursued 
their  journalistic  research  further  and  ultimately  formulated  the  design  oi  their  ex- 


planation  facility  from  their  findings.  Surprisingly,  the  foundation  of  their  design 
is  based  on  some  very  familiar  principles  introduced  by  a  man  named  Shuman  in 
1903.  These  principles  form  the  foundation  of  news  reporting  and  are  as  relevant 
today  as  they  were  eighty  some  years  ago.  They  are  called  the  Jive  IV’s. 

Wick  and  Slagle  based  their  design  of  .JOE  on  these  five  Ws  (  Who,  What.  Where. 
When,  and  Why)  and  a  si.xth  principle  -  How  (which,  for  information  purposes  was 
added  to  the  list  of  five  Ws  later).  Their  basic  goal  was  to  design  a  system  that 
would  extend  the  two  basic  HOW/WHY  capabilities  of  current  practice  systems 
to  the  six  just  identified.  They  realized  that  the  explanations  this  system  would 
produce  could  only  deal  with  basic,  surface  level  information  but  were  convinced 
that  this  type  of  information  could  still  provide  highly  informative  e.\planations. 
The  final  result  of  their  work  can  provide  eighteen  different  explanations  —  the  six 
basic  questions,  each  answered  in  past,  present,  and  future  tense. 

7.4.3  Contributions 

JOE  is  a  relatively  new  system  and  definitely  a  new  concept  in  explanation  gener¬ 
ation.  How  significant  this  work  will  turn  out  to  be  is  yet  unknown.  However,  one 
feature  used  in  JOE  is  quite  interesting.  This  feature  has  to  do  with  the  use  of  time 
stamps  to  determine  relational  links  between  data  values  without  having  this  infor¬ 
mation  explicitly  stored  in  the  knowledge  base.  Different  time  stamps  are  used  for 
different  types  of  information  based  on  the  origin  of  that  information.  For  example. 
user  entered  values  receive  a  time  stamp  from  the  system  clock  at  the  time  they 
are  entered  into  the  system,  default  values  receive  a  boot-time  stamp  which  is  set 
at  the  beginning  of  the  E.S  execution,  and  inferred  values  receive  the  largest  time 
stamp  of  the  data  from  which  they  are  inferred.  Based  on  this  information.  Wick 
and  Slagle  developed  several  equations  that  compared  the  time  stamp  values  and 
determined  if  the  relational  link  between  two  pieces  of  data  was  inferred,  default,  or 


7.4.4  Conclusion 


The  work  (lone  in  JOE  has  approache<J  the  issue  of  explanation  generation  from  a 
more  pragmatic  viewpoint  than  any  of  the  other  systems  we  have  examined.  Dis¬ 
covering  new  and  exciting  ways  of  producing  high  level  explanations  was  not  the 
goal  of  this  work,  yet  enhancing  explanation  generation  detinitely  was.  Idenlilying 
the  relationship  between  current  EFs  and  newspaper  reporting  i.s  c[uite  interesting 
and  provides  a  mechanism  for  enhancing  many  of  the  explanation  capabilities  ot 
existing  ESs  and  ES  shells. 

7.5  Summary 

Each  of  the  systems  examined  in  this  chapter  have  made  specific  contributions  to 
EF  research  and  development.  BLAH  has  provided  significant  advances  in  providing 
Function  2  (and  some  Function  3)  capabilities  with  its  use  of  the  user  view  knowledge 
base  and  its  various  explanation  restructuring  techniques.  CLE.AR  has  provided  in¬ 
valuable  information  concerning  the  knowledge  content  of  rules  and  has  identified  a 
domain-independent  methodology  for  gaining  access  to  this  information.  .lOE  has 
provided  the  mean.s  of  enhancing  existing,  commerically  used  ES  explanation  lacil- 
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ities  without  requiring  a  major  rewrite  of  the  system  by  recognizing  the  similarities 
between  the  task  of  the  newspaper  writer  and  the  functionality  of  existing  EFs  using 
the  well  established  concepts  and  ideas  from  the  journalism  profession. 


Chapter  8 

Wrapping  It  Up 

8.1  Overview 

The  purpose  of  this  final  chapter  in  our  review  of  erplaiiation  generation  research 
and  development  is  to  provide  a  summary/conclusion  to  this  topic.  This  will  be 
done  using  some  of  the  ideas  and  concepts  developed  by  Roger  Schank  and  his 
group  of  researchers  at  the  Yale  University  AI  Laboratory.  .After  briefly  discussing 
the  underlying  philosophy  behind  this  work  we  will  use  several  of  its  key  points  as 
the  basis  for  summarizing  where  we  have  been  and  identifying  where  we  are 
going  in  explanation  generation  research  and  development. 

8.2  A  New  Focus 

Schank,  in  his  book  Explanation  Patterns:  Understanding  Mechanically  and  Crea¬ 
tively  [27],  identifies  an  interesting  new  focus  for  explanation  generation.  .As  his 
title  indicates,  this  focus  deals  with  the  issue  of  machine  undeistanding  and  what 
it  means  for  a  machine  to  do  this,  a  topic  that  is  one  of  the  most  fundamental  and 
controversial  issues  in  .AI.  Schank  explains  that  to  understand 

"is  to  satisfy  some  basic  desire  to  make  sense  of  what  one  is  processing,  to 
learn  from  what  one  has  processed,  and  to  formulate  new  desires  about 
what  one  wants  to  learn.’’  [27,  page  19] 
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lie  idenlilies  three  laetors  that  he  says  "are  inextricably  bound  together  '  in  making 
up  this  definition:  txplanatiotK  Itaniimj.  and  creativity.  Furtlierinore.  he  notes  tliat 

"F.xplaining  the  world,  to  others  and  to  oneself,  is.  in  essence,  the  heart 
of  understanding.”  [27.  page  lb] 

In  relating  explanation  to  understanding  Schank  defines  something  he  calls  the  un- 
derstandinij  .spectrum.  This  spectrum  provides  a  measure  or  gage  for  determining 
just  how  strongly  (or  weakly)  related  any  one  explanation  is  to  understanding  - 
how  well  it  understands.  There  are  three  markers  along  this  spectrum  that  Schank 
identifies. 

1.  .Makiny  Sense:  Ihis  type  of  understanding  is  at  the  lowest  end  of  the  spec¬ 
trum  and  represents  understanding  at  the  level  of  being  able  to  identify  what 
seciuences  of  actions  an  ES  has  followed  during  its  reasoning  process. 

2.  Cognitive  Understanding:  This  type  of  understanding  falls  in  the  middle  of  the 
spectrum  and  represents  understanding  at  the  leieJ  of  being  able  to  explain 
why  an  E.S  came  to  the  conclusions  it  did,  what  hypotheses  it  rejected  and 
why.  how  previous  experiences  influenced  it  to  come  up  with  its  hypothesis, 
etc. 

d.  Complete  Empathy:  This  type  of  understanding  is  at  the  highest  end  of  the 
spectrum  and  represents  understanding  at  the  level  of  an  ES  being  able  to 
satisfy  an  examiner  or  inquirer  in  the  same  way  that  a  human  would  (if  that 
human  were  in  a  similar  situation). 

It  is  important  to  point  out  that  Complete  Empathy  is  the  category  or  degree  of 
understanding  Schank  feels  is  the  cause  of  all  of  the  controversy  with  respect  to 
.\I  and  it  capabilities.  He  goes  on  to  note  that  he  does  not  believe  machines  will 
ewer  reach  this  level  of  understanding  (provide  this  type  of  explanat  ion )  in  its  fullest 


sense.  Hus  is  because  complete  empathy  requires  two  individuals  to  experience  the 
same  experiences  and  react  to  them  in  the  same  (or  very  similar)  ways  and  Schank 
doesn  t  believe  machines  will  ever  experience  enough  of  these  experiences  or  react 
to  them  in  the  proper  way(s)  to  satisfy  you  or  I  that  it  really  understands  us.  .A.s 
Schank  points  out.  we  humans  are  extremely  lucky  if  we  find  just  one  person  during 
our  entire  lifetime  that  satisfies  the  criterion  for  complete  empathy. 

This  point  aside,  it  is  this  understanding  spectrum  and  the  important  relation¬ 
ship  between  explanation  and  understanding  that  we  want  to  use  as  the  basis  for 
our  review  and  preview  of  EF  research  and  development. 

8.3  Where  We  Have  Been 
8.3.1  The  User 

In  identifying  explanation  as  the  essence  of  understanding,  Schank  lists  two  audi¬ 
ences  toward  which  these  explanations  are  to  be  directed:  others  and  oneself.  In 
looking  at  where  we  have  been  with  respect  to  the  previous  chapters  of  this  paper, 
the  first  itnportant  point  to  note  is  that  the  audience  toward  which  all  of  this  work 
has  been  directed  is  what  Schank  calls  the  others,  people  outside  the  system  in¬ 
terested  in  understanding  how  and  why  the  system  works  the  way  it  does.  While 
this  may  not  seem  surprising,  some  interesting  points  and  questions  can  be  raised 
concerning  the  specifics  of  this  audience. 

First,  the  majority  of  the  work  we  have  examined  in  this  paper  has  concerned 
itself  with  medical  consultation  type  systems.  The  entire  MYC'IN  family.  Digitalis 
and  XPL.YIN.  and  much  of  Chandrasekaran's  work  on  generic  tasks  dealt  with  these 
types  (T  systems.  This  being  the  case,  a  valid  question  concerning  the  validity  and 
relevance  ol  this  work  beyond  its  specific  applicaticm  domain  can  be  raised.  Not  all 
FvSs  are  medical  and/or  consultation  systems.  The  military  uses  numerous  ESs  that 
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are  einlaedcied  componeiUs  oi  larger  weapons  and  coinmuidcaliuns  systems.  1  liese 
systems  don't  interact  witli  a  user.  Industry  also  has  numerous  iion-interactive 
applications  for  ESs  in  such  areas  as  process  control  and  robotics.  Why  do  these 
systems  need  an  e.xplanation  facility  when  there's  no  one  to  e.xplain  anything  to.' 
The  answer,  of  course,  was  first  identified  in  Chapter  '2  and  further  discussed  in 
.KPL.\L\  and  EES.  EEs  are  an  e.xtremely  important  software  engineering  tool  and 
since  every  ES  must  go  through  a  software  development  cycle.  EEs  will  always  be 
an  important  part  of  any  ES.  However,  using  EEs  in  non-consultative  type  systems 
as  software  engineering  tools  identifies  a  second  interesting  point. 

ESs  that  are  embedded  in  large  systems  need  the  del)ugging.  testing,  mainte¬ 
nance.  and  documentation  features  that  EFs  can  provide.  In  addition,  they  require 
some  kind  of  user  interface  for  use  by  the  system  developers.  Howe\’er.  once  the 
system  has  been  finished  and  is  ready  to  be  used  operationally  (ready  to  be  embed¬ 
ded  into  it.s  larger  system),  the  EF  is  no  longer  needed.  This  implies  the  need  for 
a  ttiodular  approach  to  EF  development,  creating  an  EF  that  can  be  attached  to 
a  system  when  its  .software  engineering  capabilities  are  needed  and  then  detached 
from  the  system  before  it  goes  online.  However,  this  apparent  requirement  creates  a 
major  conflict.  Throughout  the  literature  it  is  emphasized  that  explanation  gen¬ 
eration  capabilities  can’t  simply  be  added  to  an  existing  ES,  but  must  be 
a  major  consideration  in  the  design  and  development  of  an  ES  from  the 
very  beginning.  If  the  types  of  knowledge  an  EF  needs  are  intricately  woven  into 
the  design  of  the  ES,  how  can  the  EF  be  attached  and  detached  on  an  as-needed 
basis?  One  possible  answer,  I  think,  can  be  found  in  Cfhandrasekaran's  generic  task 
approach.  If  explanation  generation  is  viewed  as  a  natural  capability  implicitly  pro¬ 
vided  in  the  structure  of  the  specific  task  to  be  performed  instead  of  as  a  se[)nrate. 
specific  requirement  of  an  ES  (with  its  own  special  types  of  knowledge  and  jU'ocess 


iiig  ^cheiiies).  tlien  the  only  module  that  needs  to  be  att.nhed  and  detached  is  the 
one  that  provides  the  interface  to  the  user. 

8.3.2  The  Understanding  Spectrum 

In  vit'vving  our  previous  discussions  (Chapters  3-7)  with  respect  to  Schank's  iin- 
(lerstandinfj  spectrum,  we  hud  that  a  natural  progression  from  the  most  elementary 
torin  of  understanding  toward  a  more  robust  form  has  taken  place.  .As  Schank  notes 
(and  is  obvious  from  our  discussion  of  MA'CIN)  this  system  provides  explanations 
that  fit  into  the  understanding  spectrum  at  the  Making  Sense  level.  Using  the  trace 
ol  its  execution  contained  in  its  history  tree,  .MA’CIN  is  able  to  explain  the  sec|ueiice 
of  actions  it  performed  in  its  reasoning  process. 

W  hile  the  rest  of  the  MARGIN  family  also  contributed  towards  improved  under¬ 
standing,  the  significance  of  these  contributions  varied.  TEIRESI.AS's  information 
metric  did  help  increase  the  understanding  level  of  the  user  by  presenting  various 
degrees  of  explanation  sophistication.  However,  the  real  contributions  in  under¬ 
standing  came  from  the  work  done  in  GUIDON  and  NEO.VIA’CI.N.  While  their  work 
on  explaining  control  strategies  falls  short  of  providing  complete  Cognitive  Under¬ 
standing.  it  definitely  improves  MYCiN’s  initial  understanding  level. 

Swartout's  work  in  Digitalis  improves  only  slightly  on  MYCIN's  initial  under¬ 
standing  level  and  would  therefore  fall  slightly  to  the  right  of  .MYCIN  on  the  under¬ 
standing  spectrum.  This  slight  improvement  of  course,  is  contained  in  the  proce¬ 
dural  approach  that  Swartout  used  and  the  ability  the  system  had  to  explain  these 
procedures.  However,  significant  improvements  were  made  in  XPL.AIN.  While  still 
falling  short  of  complete  Cognitive  Understanding  (as  Schank  defines  it),  the  au¬ 
tomatic  programming  concept  used  in  this  system  captures  much  of  the  missing 
programmer  information  needed  for  better  explanations  (explanations  that  are  more 
understandable).  EES  further  extends  the.se  improvements,  coming  even  closer  to 


fitting  Schaiik's  definition  of  Cognitive  rnderslariding. 

Chandrasekaran's  work  with  generic  tasks  is  difficult  to  asses.  The  overall  con¬ 
cept  definitely  appears  to  provide  the  capabilities  necessary  to  produce  explanations 
on  the  level  of  Cognitive  Cnderstanding.  However,  as  no  real  analysis  of  the  effec- 
tivf'ness  of  this  concept  has  been  provided,  we  can  only  speculate. 

Kach  (jf  the  systems  discussed  in  chapter  7  were  designed  to  improve  \arious 
aspects  of  an  ES's  explanation  generation  capabilities.  From  this  staudpijini.  each 
was  concerned  with  helping  improve  the  level  of  understanding  provided  In  these 
rps.  However.  1  think  it  is  safe  to  say  that  each  of  these  systems  would  fall  just  to 
the  right  of  the  Making  Sense  level  on  the  spectrum. 

8.4  Where  We  Are  Going 

.■\s  already  noted,  all  of  our  previous  discussions  have  dealt  with  systems  whose 
FFs  were  designed  with  some  outside  user  in  mind.  Whether  this  user  is  a  dotnain 
expert  or  system  developer  is  not  important.  What  is  important  is  that  in  looking 
at  one  direction  of  where  we  are  going  in  future  EF  research  and  development,  we 
must  change  our  focus  of  attention  and  concentrate  on  the  second  audience  .Schank 
identified,  that  being  oneself  (which  in  our  ca.se  refers  to  the  system  itself). 

.As  mentioned  earlier.  Schank  believes  explanation,  learning,  and  creativity  are 
wrapped  up  together  in  defining  underslan<lin<j.  This  is  based  on  his  observation 
that  understanding  is  a  dynamic  entity  that  changes  over  time  and  that  people 
adapt  to  new  circumstances  by  changing  their  behavior.  Schank  argues  that  we 
do  tills  through  self-explanation.  He  points  out  that  when  we  explain  things  to 
ourselves  we  are  attempting  to  correct  some  initial  misunderstanding  by  tiiuling 
relevant  eyperierices  we  have  had  that  might  account  for  the  misunderstood  e\-ent 
or  situation.  When  we  do  this  we  obtain  a  new  understanding,  creating  a  new 


(.'xplanat lull  ot  lhi.s  iiiulcrsi aiuliiig  as  a  result.  Schank  argues  that  the  erealiviiy 
involved  in  coining  up  with  this  new  explanation  is  the  ('ssence  of  what  it  nu'aiis  to 
think  and  therefore  the  heart  ot  what  we  mean  by  understanding.  He  also  argues 
that  this  creatic'ity  is  not  some  magical  gift  we  humans  possess,  but  rather  is  a 
mechanistic  process  that  is  possible  for  computers  to  replicate.  Work  is  currently 
being  Conducted  in  developing  such  a  process  and  is  the  major  em[diasi.'  ot  Schank  s 
l)ook  27  .  W  liile  this  process  is  beyond  the  scojie  of  this  paper,  the  import.uii  point 
to  note  Is  that  otie  tutttre  direction  <jf  HF  ix'search  is  in  the'  ao'a  i.>t  il 

i  sphiunt n)n>  for  tin’  pitrpose  ot  developing  machines  that  are  creative. 

Interestingly,  creativity  is  not  the  otdy  motivaiion  irehind  sell-ihrected  ex]jla- 
nations.  Hammond  [HtJ  has  been  working  oii  a  planning  system  that  uses  causal 
explatiat  ions  to  repair  piatis  that  initially  fail.  Plan  failures  are  descrilted  in  terms 
of  causal  explanations  of  why  they  occurred  and  then  used  to  access  ditfereiit  al> 
stract  [jlanning  strategies,  which  .  once  an  apitropriate  strategy  is  tc'"  d.  results  in 
a  sfiecitic  change  In'ing  made  to  the  faulty  plan.  The  irnportatit  point  to  recogtiize 
here  is  that  the  causal  (.'xplanations  generated  tor  use  by  the  system  are  the  exact 
'ame  exidanat  iotis  that  would  be  [>resented  to  an  inciuisitive  user.  They  are  not 
'oiiie  'jcecial  new  form  ol  explanaticni. 

.\  higher  degree  of  uudt'tst anditig  is  the  goal  of  Eh'  research  and  developtnenl. 
.\'ot  >urprising  is  the  fact  that  this  focus  oti  utiderstanding  is  lutidamental  to  the 
d'-hnitioti  of  I'xplanation  wc'  established  in  (.'hapter  1.  However,  pri'seiitmg  tlicso 
'■vjdaiiai  KUi'  to  the  system  it-i-H.  a.-*  well  as  to  an  iinjuisitive  outside  u.-'er.  .ippears 
to  li-’  lli-‘  dli  ectioll  ol  lilt  me  f.h  resea t'l  l  aild  ilevclopllieut  . 


Chapter  9 


EFFESS:  Background 
Information 

9.1  Overview 

As  identified  in  the  introduction  to  this  thesis,  this  work  on  explanation  (jentralion 
in  E.Ss  is  being  conducted  from  two  different  points  of  view  and  is  part  of  a  larger 
['('search  and  development  effort  being  conducted  at  Wright  State  University  into  the 
use  of  two  important  (and  somewhat  conflicting)  technologies:  software  engineering 
irtth  Ada  and  AI  applications.  The  purpose  of  this  chapter  is  to  provide  some 
imf)ortant  background  information  concerning  the  second  aspect  of  this  the.  is,  the 
implementation  of  EFFESS.  Specifically,  this  chapter  will  first  describe  the  ES  shell 
u.sed  in  this  project.  It  will  then  discuss  the  initial  requirements  of  this  project  and 
re-examine  the  literature  review  in  order  to  identify  the  concepts  and  ideas  that 
have  influenced  it.  Additionally,  information  taken  from  sources  not  presented  in 
the  literature  review  will  also  be  discussed. 


9.2  The  ES  Shell 

I  he  I'.S  shell  b<,‘ing  used  in  I'iFF'ESS  was  developed  by  (,'apt  .James  Cardow  as  j^art 
(jf  his  master's  degree  requirements  [.5]  and  represents  one  effort  resulting  from  the 
Ada  and  AI  w(;rk  being  done  at  Wright  State  University.  In  order  to  understand 
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miu'l'i  ul  will  suon  iic  (iiscussi'il  with  rcsix'ct  to  LFhl'.SS.  a  basic  dcsciipi  iuii  ol 

this  FS  shell  is  needed. 

Cardow's  shell  was  designed  using  the  Object  Oriented  Frugraiiuning  lOOP) 
design  met hodology,  partly  bec'ause  .Ada  supports  this  methodology  and  partly  be- 
caus<'  OOP  is  closely  related  to  the  jramt-bastd  KRS  Cardow  chose  to  use.  Peasoii- 
ing  within  the  system  is  pertormed  by  using  either  3.  forward-rham ing  (tlafa  di-ii’ful 
process,  a  hack'ward-chdinitKj  (hijpothesis  driven)  process,  or  a  combination  of  both 
of  these  processes.  Information  in  the  system  is  stored  in  a  hierarchg  of  franu.',  and 
can  be  j^assed  between  these  frames  bv  using  inherit anct  or  by  j)assing  mtssn(jt>. 
Demons  are  attached  to  the  slots  of  the  frames  and  represent  the  rxevution  mech¬ 
anism  of  the  system.  Fach  type  of  demon  performs  a  specific  function  on  the  slot 
to  wliich  it  is  attaclied  and  accomplishes  this  function  by  processing  or  firing  an 
associated  set  of  production  I'ultfsj. 

W  Idle  this  description  is  by  no  means  complete  (the  interested  reader  is  referred 
to  [oj  for  complete  details  of  Cardow'.s  work),  it  does  identify  the  key  features  of  the 
ES  shell,  [  he  fundamental  goal  of  EFFESS  is  to  explain  these  different  features  to 
a  user  of  the  system  and  to  do  so  in  an  understandable  way. 

9.3  Initial  Requirements 

riiere  are  two  major  requirements  for  EFFE.SS  that  need  to  be  discussed  as  part 
of  the  background  information  for  this  project.  These  are:  the  use  of  .Ada  as  the 
implementation  language  for  the  project  and  the  decision  to  add  an  EE  to  an 
existing  system  rather  than  include  an  Eh'  in  the  design/redesign  of  an  ES.  FliC 
reason  if  i.^  nn[)ortant  ro  uinlerstand  tfic'se  resjuirements  is  Ijcc.iuse  they  detine  the 
scope  (d  the  FFh  F.SS  project. 

I  Ilf'  nef'd  to  im  hide  sound  software  f'ligitieering  practices  in  the  fle\'elo|)ment 


I. 


it  aii\'  cuniputer  j^ottware  sysiciii  is  a  u<‘ll  acteptcd  fact.  Oit>‘  unpurtaiu  asj^i-ct 
ot  cioing  this  is  to  use  implementation  languages  that  explicitly  provide  software 
engineering  constructs  as  part  of  the  language.  .Ada  was  specifically  designed  to  be 
one  ot  these  languages.  However,  the  extremely  flexible,  rapid  [irototyping  languages 
specifically  designed  for  .AI  research  and  development  (LISP  and  PROLOG)  were 
not  designed  with  software  engineering  support  in  mind.  W  hile  their  use  in  an 
academic  or  research  laboratory  type  .setting  has  been  acce[>Led.  as  more  and  more 
of  .M's  technology  (i.e.  expert  system  technology)  moves  out  of  this  setting  and 
into  an  operational,  on-line  environment,  the  use  of  software  engineering  intensive 
languages  to  develop  these  .AI  systems  must  be  investigated.  1  bus.  the  use  of  Ada 
as  the  implementation  language  for  EFFESS  is  one  requirement. 

The  requirement  to  add  an  EF  rather  than  include  its  requirements  and  spec¬ 
ifications  in  the  design  or  redesign  of  an  ES  developed  from  three  different  sources. 
The  first,  which  was  initially  identified  in  Chapter  8.  deals  with  the  need  established 
tor  a  plug-in  type  EF  that  provides  a  testing  and  debugging  type  explanation  capa¬ 
bility  for  ESs  that  are  ultimately  going  to  be  embedded  into  larger  systems  of  some 
kind.  The  sojcond.  which  was  initially  identified  in  (.'hapter  7  during  the  discussion 
of  Wick  and  Slagle's  work  on  .lOE  [31],  deals  with  the  issue  oifiinctLonality  crc.^ics 
rost.  W  ick  and  Slagle  recognized  that  many  operational  ESs  (ones  they  called  prac¬ 
tice  systems)  needed  an  EF  but  could  not  afford  to  go  through  a  major  redesign 
in  order  to  acquire  some  of  the  sophisticated  explanation  capabilities  we  have  ex¬ 
amined  in  previous  chapters.  They  also  recognized  that  an  t  fftctive  EF  could  be 
j)rovided  without  going  through  this  redesign  process.  Fherehue.  their  effort  was 
cf)iicentrated  on  providing  effective  EFs  for  on-line  ESs  without  making  major 
modifications  to  the  original  ES  code,  an  effort  that  was  direi  tly  appli(  able 
t(^  this  project.  I  he  third  contributing  source  to  this  reciuirement  was  the  frann  - 


b<is(<l  KHS  Cardow  chus*'  to  use  in  the  KS  sliell.  After  exaniiiiiug  (  'ardou' '.i  iliell. 
definite  sn[  port  existed  for  viewing  this  reouirement  as  a  feasible  one.  (Chapter  lU 
discusses  this  frame-based  KRS  in  detail  and  identifies  the  contributions  it  makes 
to  explanation  generation.) 

9.4  The  Literature  Review  Revisited 

.\s  identified  in  the  introduction  to  thi.s  thesis,  the  purpose  of  the  literature  review 
wa.s  to  establish  a  knowledge  base  to  draw  from  in  determining  the  functionality  and 
development  of  EFFESS.  As  it  turned  out,  this  knowledge  base  is  quite  large  and 
includes  a  wide  range  of  topics  related  to  explanation  generation  in  FSs.  not  all  id 
which  are  applicable  to  this  effort.  This  section  identifies  those  concepts  and  ideas 
that  have  been  taken  from  this  knowledge  base  and  used  (in  one  way  or  another)  in 
EFFESS. 

•  MYCIS  (Chapter  3)  :  The  basic  functionality  of  MYCIN's  Reasoning  Status 
Checker  (RSC)  is  used  in  EFFESS.  In  addition,  the  two  example  questions 
li.sted  for  the  RSC  are  implemented.  While  the  functionality  of  the  GQ.-\  was 
considered,  its  requirement  for  natural  language  processing  was  determined  to 
be  beyond  the  scope  of  this  project.  However,  access  to  the  different  types  of 
information  required  by  the  GQA  is  made  available  in  EFFESS. 

•  The  MYCTN  Family  (Chapter  4) 

1.  TEIRESIAS  :  The  four  step  process  Davis  identifies  as  being  lu'cessary 
to  design  an  EF  was  used.  Chapter  11  presents  a  discussion  of  EFFESS' 
design  process  using  these  four  steps. 

2.  (II  TOON  :  While  specific  use  of  meta-rules  was  not  needed  in  Ef  fESS. 
metn-knoirledge  concerning  the  implicit  inheritance  control  mechanism  of 


the  frame- based  KRS  was  used. 

XEOMYCiy  :  The  prirrary  focus  of  NEOM\'CI.\  was  on  txphiiuiiig  di 
agnostic  strategies.  While  EFFESS  does  provide  a  limited  capability  in 
tins  area,  little  of  the  work  done  in  .\EOVIY(i'IN  was  used. 

•  Explicit  Development  Models  (Chapter  -o)  :  Most  of  Swartout's  work  involves 
the  ca{)turing  and  e.xplanation  of  deep  knowledge.  While  his  aatumntyj  prn- 
priiin  writer  is  an  interesting  concept,  providing  this  type  of  functionality  is 
beyond  the  scope  of  this  project.  However,  two  aspects  of  EFFESS  can  be 
traced  back  to  Swartout's  work.  First,  the  production  rules  in  the  system 
were  encoded  using  descriptive.  English-like  names.  This  is  a  powerful  feature 
of  .Ada  and  allows  EFFESS  to  produce  very  descriptive  e.xplanatioiis  without 
having  to  concern  itself  with  English  translations  of  rules,  te.xt  generators,  etc. 
Swartout  used  a  similar  capability  in  The  Digitalis  Therapy  .Advisor.  Second. 
Swartout  recognized  the  software  engineering  assistance  EEs  can  pros'ide.  .As 
has  already  been  identified,  creating  a  plug-in  software  engineering  tool  is  one 
of  the  reciuirements/objectives  of  this  project. 

•  Generic  Tasks  (Chapter  6)  :  Chandrasekaran's  development  of  specific  design 
languages  in  support  of  his  generic  tasks  is  beyond  the  scope  of  this  project. 
However,  an  interesting  observation  concerning  this  project  and  these  generic 
tasks  is  presented  in  Chapter  12. 

•  .4  Potpourri  of  EEs  (Chapter  7) 

1.  BLAH  :  .None  of  Weiner’s  work  in  BL.AH  is  used  in  EFFES.S  because 
major  changes  to  the  E.S  shell  would  be  required.  However,  a  discussion 
of  his  system  view  and  his  user  new  with  respect  to  fT  FF.S.S  is  presented 
in  Chapter  I '2. 


2.  CLEAR  :  RubinofF's  CLEAR  system  was  designed  to  be  an  attachable 
Iront-end  to  an  independently  developed  ES.  While  none  of  the  func¬ 
tionality  of  CLEAR  is  included  in  EFFESS,  the  basic  design  goal  of 
CLEAR  is  one  of  the  primary  objectives  of  this  project. 

3.  -JOE  :  Wick  and  Slagle's  work  on  .JOE  has  been,  by  far.  the  most  in¬ 
fluential  on  this  project.  The  applicability  of  their  basic  philosophy  was 
identified  earlier  in  this  chapter.  In  addition,  four  of  the  si.x  functions 
they  provide  in  .JOE  are  implemented  in  EFFESS:  WH.AT.  WHERE. 
WHY.  and  HOW.  (However,  these  four  functions  are  not  presented  in 
three  different  tenses,  as  was  done  in  .JOE.) 

\\'hile  we  are  discussing  the  literature  information  that  has  influenced  the  develop¬ 
ment  of  EFFESS,  one  article  not  presented  in  the  literature  review  needs  to  be  men¬ 
tioned.  In  one  section  of  their  article.  Building  Knowledge- Based  Systems  with  Pro¬ 
cedural  Languages  [3].  Butler.  Hodil,  and  Richardson  discuss  EFs.  In  their  discus¬ 
sion  they  identify  three  functions  that  an  EF  should  perform:  the  Rule  Query,  the 
Why  Query,  and  the  E.xplain  (or  How)  Query.  .Additionally,  they  identify  the  use 
of  a  stack  as  an  appropriate  data  structure  for  maintaining  a  trace  of  the  system's 
performance.  .All  of  this  information  is  included  in  the  functionality  of  EFFESS. 
However,  the  implementation  of  the  Why  Query  and  the  How  Query  vary  from  the 
descriptions  Butler,  Hodil,  and  Richardson  provide  for  these  functions.  EFFESS's 
1*  ^  and  Why  functions  are  based  on  MARGIN’S  interpretation  of  what  these  queries 

mean.  The  reason  for  this  difference  stems  from  the  fact  that  both  systems  are 
avoiding  the  problems  of  natural  language  processing  by  explicitly  defining  what  is 
meant  by  Why  and  How.  As  these  two  words  have  several  different  meanings  (hence 
the  problems  associated  with  natural  language  processing),  MA'CIN  has  defined  the 
functionality  of  these  queries  differently  than  Butler.  Hodil.  and  Richardson.  We 


have  chosen  to  implement  M't'CIX's  version. 


9.5  Summary 


riiis  cliapter  lias  presented  important  background  information  concerning  the  MS 
shell  that  is  to  be  explained,  the  initial  reqnirements  established  for  the  project, 
and  the  (xnicepts  and  ideas  tliat  have  been  taken  from  the  literature  on  explanation 
generation  and  used  in  the  de\’elopment  of  EFFESS. 


Chapter  10 

EFFESS:  A  Frame-Based  System 


10.1  Overview 

One  ot  the  most  important  aspects  of  our  project  is  that  it  involves  the  explanation 
ot  a  jran)f:-b<istd  IxRS.  l  lieretore.  to  understand  the  specifics  of  this  implementa¬ 
tion  effort,  a  detailed  examination  of  this  KRS  is  reciuired.  'I'he  purpose  of  this 
chapter  is  to  provide  this  detailed  examination.  Interestingly,  there  are  several  dif¬ 
fering  opinions  within  the  .A,!  community  concerning  the  definition  of  a  frarne-hn.'fo.d 
knowledge  representation  structure  or  frame-based  system.  While  understanding 
these  differences  is  not  important  for  our  discussion,  understanding  the  two  fun¬ 
damental  KR.Ss  upon  which  they  are  based  is  important.  Fheretore.  this  chapter 
begins  by  discussing  these  tw'o  KRSs  (rule-based  and  frames)  individually,  as  the 
basis  for  understanding  the  KRS  used  in  EFFESS.  Once  this  understanding  has 
been  established,  a  description  of  our  frame-based  KRS  will  be  presented,  followed 
by  a  discussion  of  the  contributions  it  makes  to  explanation  generation. 

10.2  A  Rule-Based  KRS 

10.2.1  Background 

In  his  chapter  or  Production  Systems  (which  is  another  name  foi  a  Rule-Based  ES) 
[17.  chapter  10].  Firebaugh  notes  that  tin*  concept  of  a  production  system  or  a  ruh  - 


s\ stem  was  liist  int rodua'tl  by  Kiuil  I'ost  in  llJd3.  lie  goes  on  to  sa\-  that, 
this  ty[)e  ot  system  was  proposred  as  a  model  ot  human  problem-scdeing  beha\'i<u' 
(the  context  in  which  it  is  used  in  AI)  by  Allan  Newell  and  Herbert  Simon  in  HJTi. 
This  problem-solving  model  and  KRS  have  had,  and  continue  to  have,  a  signihcant 
impact  on  LS  development.  Much  of  the  work  described  in  chapters  3  -  7  of  this 
thesis  are  production  systems,  using  rule-based  KRSs. 

10.2.2  Composition 

There  are  three  main  components  of  a  rule-based  ES. 

1.  hnoiL'hdge  Base  (KB):  The  KB  consists  of  a  set  of  if  —  thtn  or  condition 
—  action  rules,  (i.e.  /(/condition  then  action)  The  expert  knowledge  for  the 
system  is  encoded  in  these  rules. 

2.  (.'ontrol  System  :  .\lso  known  as  the  inference  enyini.  this  part  of  the  system  is 
the  rule  interpreter  and  rule  orderer/sequencer.  The  control  system  provides 
the  processing  direction  and  operation  needed  to  run  the  ES. 

3.  DataBase  :  The  database  is  the  storage  facility  that  contains  the  iid'ormation 
the  rule  conditions  evci\ua.le  and  upon  which  the  rule  actions  act. 

10.2.3  Strengths 

Eirebaugh  [17]  identifies  four  major  strengths  that  have  made  rule-based  systems  so 
popular.  These  are: 

1.  Natural  Representation  :  A  rule-based  KRS  provides  a  natural  way  to  rep¬ 
resent  the  if  such  and  such,  then  do  such  and  such  "  type  situations  often 
/'ucountered  by  human  experts. 

2.  Simple  Construct  :  .\  rule-based  KRS  is  a  simple,  uniform  way  to  repre¬ 
sent  knowledge.  I  he  if  ---  then  construct  of  the  produciion  rule  is  easy  to 


unitlfiiK'nl.  IS  tiiiu’s  sclt-doriuneiil iiig.  helps  siniplil\'  the  1^111111111111  atieii 

between  difterent  parts  ot  the  system,  and  aids  in  providin';;  Kiiglishdike  defini¬ 
tions  of  the  rules  fa  factor  that  M\'CL\  e.xploited  in  prodiiciiig  its  English-like 
explanations). 

.'5.  Modular  and  Modifiahlt  :  Each  rule  in  a  rule-based  KR.S  lepresents  a  discrete 
[lieee'  of  knowledge  and  is  usually  not  directly  related  to  au\'  other  rule  in  thi' 
KB.  I  Inu'clore.  injormalion  can  be  chewed  as  a  eollei  tioii  of  indrpeiideiit  lacts. 
each  of  which  can  be  easily  modified. 

f.  Knowlrdgr  hifin.^irt  :  The  KB  in  a  rule-ba.sed  KR.S  contain.s  all  of  the  expert 
knowledge  for  the  system  and  only  this  information.  It  is  knowledge  intensive. 
Iherefore,  it  is  separate  from  the  rest  of  the  svstem.  I  his  allows  the  reuse  of 
a  particular  control  strategy  sitice  it  is  itot  dependent  on  the  KB  at  all. 

10.2.4  Weaknesses 

Eirebaugh  [IT]  identifies  two  weaknesses  or  limitations  of  production  systetiis  that 
are  worth  mentioning.  The  first  has  to  do  with  the  fact  that,  while  individual 
rules  are  clear  and  concise  and  easily  understood,  when  the\'  are  contbined  itito 
the  overall  system  this  clearness  and  conciseness  tends  to  disappear.  The  sec¬ 
ond  has  to  do  with  the  lack  of  structure  or  organization  that  exists  for  systems 
containing  large  numbers  of  rules.  Usually,  all  of  the  rules  are  contained  in  one 
large  list  or  set.  This  requires  an  e.xhaustive  search  of  this  list  or  set  each  time  a 
rule  is  needed.  Obviously  tliis  is  not  very  efficient.  While  tlu'se  two  weaknesses 
are  significant,  the  real  problem  with  rule-based  systems  (from  an  explanation 
generation  [)oint  of  view)  is  identified  by  Fike.s  and  Kehler  in  their  article  enti- 
tlefl  [  he  Role  of  Erame-Ba.sed  Representation  i.i  Reasoning  [16.  page  1)07].  Simple 


staterl,  hikes  and  Kehler  point  out  that  nde-based  systems  can  t;  diJiiK  ti 


describe  domain  objects,  or  identify  static  relationships  atnony  objects. 


10.3  A  Frame  KRS 

10.3.1  Background 

rhi?  concept  was  originally  introduced  by  Marvin  Minsky  in  1975  as  a  result  of 
his  work  on  scene  analysis  and  computer  vision. ['d'i]  Minsk\''s  conce[)t  was  bast'd 
on  the  idt'a  that  there  are  a  number  of  stereotypical  situations  that  we  encounter 
on  a  regular  basis  and  that  these  situations  can  be  represented  in  a  hierarchically 
>tructured  trainework.  For  e.xample.  a  stereotypical  room  is  made  up  ot  tour  walls,  a 
tloor.  and  a  ceiling.  Therefore,  the  top  level  of  the  hierarchical  structure  would  be 
the  room  object,  d'he  next  level  of  the  hierarchy  would  contain  six  objects;  tine  tor 
t'ach  of  the  four  walls,  one  for  the  floor,  and  one  for  the  ceiling.  The  third  level  of  the 
hierarchy  would  consist  of  the  objects  related  to  a  particular  object  in  the  second 
le\el,  For  example,  a  wall  may  have  a  door  or  window  in  it.  a  picture  hanging  on  it. 
etc.  I  herefore.  the  third  level  of  the  hierarchy  would  contain  descriptions  of  these 
objects,  relating  them  back  to  the  higher  level  object  of  which  they  are  a  part.  This 
.'t  met  Ural  breakdown  would  continue  until  the  stereotypical  room  was  adequately 
represented. 

10.3.2  Composition 

The  primary  data  structure  of  a  frame-baaed  KRS 's  the  frame.  .\  frame  describes  an 
ol.>ject  or  a  class  of  objects  and  contains  slots  that  are  used  to  identify  or  descrilie 
whatever  is  being  represented  by  the  frame.  I  h<.'  slots  of  a  tranu'  contain  one  ol 
two  types  ot  values.  They  either  contain  default  or  constant  \alues  that  clescribe 
the  object  being  represented  by  the  frame  or  they  contain  variable  \-alues  that  can 
be  changed.  ba.sed  on  the  values  of  other  slots  of  other  frames  in  the  hierarchv. 


^'l 

Additionally,  frames  can  have  sub-frauies  attached  or  related  to  them.  It  is  this 
frame  —  subdrame  structure  that  makes  up  the  hierarchy  of  this  KR.S. 

.-\nother  feature  included  in  this  KRS  is  an  implicit  control  structure  result¬ 
ing  from  the  hierarchical  relationships  of  the  structure.  This  control  structure  is 
commordy  referred  to  as  inheritance. 

10.3.3  Strengths 

Firebaugh  [17]  identifies  several  strengths  associated  with  a  frame-based  KRS. 

1.  .\  number  of  ditferent  objects  may  share  the  same  frame.  Reterring  to  the 
.■^ttirofijpical  room  example  above,  if  we  wanted  to  describe  several  different 
rooms  m  a  building,  each  of  these  rooms  could  share  the  same  basic  structure 
of  our  ■'~te  real  apical  room  because  all  rooms  (or  at  least,  most  rooms)  hac'e  tour 
walls,  a  hoor,  and  a  ceiling.  The  slot  or  attribute  values  of  these  frames  would 
be  different  for  each  type  of  room,  but  if  the  basic  .structure  were  general 
enough  it  could  be  used  to  represent  any  room. 

2.  .As  already  mentioned,  frame-based  KRSs  provide  a  natural  hierarchy  for  struc¬ 
turing  knowledge  which  often  times  captures  the  way  an  expert  thinks  of  or 
describes  some  object. 

'■].  This  structure  also  provides  a  concise  representation  of  the  relationships  that 
exist  between  different  objects,  which  in  turn  provides  lor  easy  support  oi 
information  queries  (simply  find  the  frame  and  search  its  slots  for  the  desired 
information). 

1.  This  type  of  KRS  also  provides  an  easy  mechanism  for  defining  default  values 
that  can  be  overwritten  at  a  later  time,  shovdd  the  need  ariste 


10.3.4  Weaknesses 


While  some  criticism  lias  been  raised  concerning  a  t'rame-baseii  KRS's  abilit}’  to 
handle  iih/ptcnl  situations  [17.  [^age  2!)3],  the  major  weakness  of  this  type  of  KRS 
is  again  identified  by  hikes  and  Kehler.  While  frame-based  systems  provide  a  rich 
knowlt'tlgi'  representation  structure,  they  don't  have  a  direct  facility  for  "declara- 
tively  describing  how  the  knowledge  .stored  in  the  frames  is  to  be  used",  [lb.  page 
')0o[ 

10.4  A  Frame- Based  KRS 

can  be  seen  trom  the  {irindous  two  discussions,  each  of  thiese  KRSs  has  a  major 
limitation  with  respect  to  explanation  generation  (a.s  noted  by  hikes  and  Kehlei  ).  It 
should  also  be  fair!}’  clear  that  by  combining  these  two  KRbs.  the  strengths  of  one 
owreome  the  limitations  of  the  other.  Rule-based  s\slems  can’t  define  terms,  de¬ 
scribe  oljjects.  or  identify  static  relationships  among  objects,  hrame-based  systems 
can  do  this  ciuite  effectively.  On  the  other  hand,  frame-based  systmns  can’t  declar- 
ati\(>ly  describe  how  to  process  the  knowledge  they  contain.  Rule-based  systems  do 
this  extremely  well.  Therefore,  by  combining  these  two  KRSs  a  much  more  powerful 
and  robust  KRS  is  created,  hikes  and  Kehler  provide  an  excellent  description  of  this 
new  KRS  [16]  and  it  is  thi.s  KRS  that  is  actually  used  by  (.’aidow  in  his  hS  ^hell. 

10.5  Contributions  to  Explanation  Generation 

1  lu're  are  several  contrirmtioiis  that  this  hybrid  KRS  makes  to  explanation  gcuiera- 
t  i(;n. 


!.  Because  the  prorluction  rules  are  attached  to  tlu'  slots  \  ia  ih'moiis.  a  fiiiiial 
partit Huung  of  the  rule  -.et  is  provided.  Ihiis.  a  partial  explanation  as  td 


rlu'  i;ut'[)ose  ot  a  given  rule  eaii  be  [novided  >iin[dy  1a'  exaimniiig  the  slut 
iiddrmation  to  which  it  is  attacdied. 

2.  The  hierarchical  structure  identifies  the  relationships  anicjug  ob  jects  and  allows 
tor  an  explanatory  description  of  an  object  by  simply  identifying  the  snb- 
trames  attached  to  it.  Further  explanation  ot  each  ot  the  subdrames  can  also 
be  provirled  by  identifying  the  slots  attachetl  to  eacii  sulefranie. 

•F  The  implicit  control/inferencing  mechanism  {mbfritatici )  in  this  svstem  is 
available  for  explanation  and  thus  provides  some  Function  1.  Type  .'i  exfdana- 
tion  capabilities,  hi  addition,  slot  values  that  were  determined  by  inheritance 
can  also  be  identified.  This  additional  information  enhances  the  explanation 
ot  that  [larlicular  slot. 

4.  The  hierarchical  structure  also  provides  a  logical  partitioning  of  the  knowl¬ 
edge.  Therefore,  if  an  EF  were  to  be  enhanced  by  providing  deep  descriptive 
knowledge  for  an  object,  this  information  could  be  easily  added  as  a  slot  to 
the  appropriate  frame  or  as  an  attribute  to  the  appropriate  slot. 

■T  .As  already  noted  by  Firebaugh,  this  type  of  KRS  provides  an  easy,  efficient 
process  for  handling  queries  about  the  KB  because  the  knowledge  is  so  well 
structured  and  easy  to  find. 

6.  This  KRS  provides  two  typical  representations  of  expert  knowledge  (if  —  then 
rules,  and  object  decomposition)  that  map  almost  directly  to  the  way  this 
knowledge  is  thought  of  by  experts  in  the  real  world.  Therefore,  explanations  of 
these  objects  should  provide  more  understandable  explanations  simply  because 
of  their  realistic  repre.sentations  in  the  system. 


10.6  Summary 


By  iM'csciitiiig  detailed  deseri|}t  ions  ol  two  fundaineiital  KHSs  nseil  in  AI  and  1>\ 
identilyiiiii  their  strengths  and  weakness,  this  (-hapter  has  identilied  a  pow('rl’ul  new 
KRS  created  l)y  cotnltinitig  these  two  KR.Ss.  identified  sevf'ral  (anitrilnitions  this 
new  KRS  piarvides  with  respect  to  explanation  generation,  and  emphasized  that 
this  1\RS  is  die  tiaiiiie-ljased  KliS  used  by  i-'.FFr..SS. 


Chapter  11 

EFFESS  :  Design  Functionality 

11. 1  Overview 

The  chaptei  discusses  the  design  process  used  in  developing  hl'd-d'iSS  and  describes 
the  specific  functions  EFFESS  performs.  It  then  looks  at  the  functionality  of  this 
system  with  respect  to  the  Functional  Framework  presented  in  Chapter  2. 

11.2  The  Design 

In  deciding  how  to  go  about  designing  FF’FFSS.  two  concepts  or  ideas  were  used. 
The  hrst  was  Davis'  four  step  design  process  for  EFs  piesented  in  Chapter  Ts 
discussion  of  TEIRESIAS.  The  second  was  the  OOP  methodology  used  by  Cardow 
in  designing  the  original  ES  shell. 

11.2.1  Davis’  Four  Step  Design  Process 

Repeating  the  information  presented  in  Chapter  4.  the  four  steps  Davis  describes 
for  designing  an  EF  are; 

1.  Determine  the  program  operation  that  is  to  be  viewed  as  primitive. 

2.  .Augment  the  program  code  to  leave  a  trace  or  record  of  the  .sv.stem's  behavior 


at  the  level  of  detail  chosen  in  (1). 
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3.  Sclt'i  i  ,i  glulial  frainrwuik  in  which  the  trace  or  rectnxl  can  be  iiiuhn  stcnel. 

1.  Design  a  prcgrani  that  can  explain  tlie  trace  or  record  to  tlie  xser. 

I  hese  stt'[)s  will  now  be  discussed  with  re^pe^-t  to  how  they  w.n-e  applied  in  the 
design  of  EFFESS. 

The  primitive  operation  chosen  for  EFFFSS  is  the  same  as  the  one  l)a\is  chose 
lor  I  FIRFSIAS,  the  invocation  or  Jiving  of  a  rule.  While  tlu*  (‘xt'cution  uf  the 
(ivnions  in  our  frame-based  system  is  identified  as  providing  the  execution  (.(Uitrcdi 
ot  the  system,  demons  are  not  the  most  primitive  operation.  I  lie  s[)('cific  o[)era- 
tion  a  particular  demoti  is  identified  to  perform  is  carried  out  Ity  liriug  the  >et  oi 
rule(s)  associated  with  that  demon.  Therefore,  the  individual  pioductioti  ruh'  is  the 
primitive  operation  in  EFFE.S.S. 

['he  execution  trace  in  EFFESS  is  a  stack  data  structure.  .As  identified  iti  Cliap- 
ter  0.  this  idea  was  taken  from  Butler.  Hodil.  and  Richardson's  article  on  using 
procedural  languages  to  build  knowledge-based  systems.  .A  stack  provides  a  straight¬ 
forward  mechanism  for  properly  recording  the  order  in  which  the  rules  were  fired. 

The  global  framework  in  which  t’  ecution  trace  can  be  understood  in  FT  f  F.SS 
is  its  frame-based  KRS.  Davis  chose  u  d  tree  for  his  work  in  I'EIRESI.A.S  bia  ausc 
of  the  backward-chaining  control  structure  used  in  MYCIN.  While  our  system  also 
provides  a  backward-chaining  control  structure  (and  a  forward-chaining  one  as  well), 
the  framework  for  understanding  the  execution  trace  (for  understanding  why  a  rule 
V  as  tested/fired  at  a  particular  time  during  the  execution  of  the  system)  involves 
information  contained  in  the  KRS.  Remember  that  information  is  passed  between 
frames  in  one  of  two  ways  (through  inheritance  or  by  passing  messages)  and  that 
demons  are  executed  when  a  slot's  value  is  requested  but  does  not  exist.  I  herefore. 
to  un<lerstand  wliy  a  rule  was  tested/fired  at  a  particular  (.irne  (as  indicated  by  the 
execution  trace)  requires  that  we  know  the  method  that  was  used  in  attempting  to 
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obtain  a  value  for  the  slot.  I'liis  information  is  contained  in  the  KKS. 

This  final  step  of  Davis's  EF  design  process  (writing  a  i)rogram  to  c.xijlain  the 
trace  to  a  user)  has  been  expanded  in  EFEESS.  This  is  because  several  of  the 
explanation  functions  of  Eh'FESS  don't  use  the  execution  trace  in  providing  their 
('xplanations.  1  hey  are  able  to  get  the  infortnation  they  need  diia-ctly  from  the 
KRS.  I  herefore.  the  EFFESS  program  (which  is  contained  in  one  .Ada  jtackage 
and  is  presented  in  the  a[)pendices)  contains  more  titan  just  the  code  related  to 
('xplaining  the  execution  trace  to  the  user. 

11.2.2  OOP 

The  OOP  design  methodology  presented  by  Booch  [1.  Chapter  4j  was  used  in 
EFfE>SS'  design  at  three  different  levels  of  abstraction.  .A  discussion  of  its  use  at 
the  highest  level  of  abstraction  (the  complete  ES  Development  Environment  level)  is 
presented  here.  EFFESS  and  the  ES  shell  are  the  two  primary  objects  that  have  to 
interact  in  order  to  provide  the  functionality  of  this  larger  system.  .As  the  ES  shell 
was  designed  using  OOP  (before  EFFESS  existed),  the  only  change  that  needed 
to  be  made  was  in  its  visibility.  The  ES  shell  has  to  have  access  to  (be  able  to 
see)  EFFESS  in  order  to  build  the  execution  trace.  It  also  has  to  have  access  to 
LFFESS's  processing  entry  procedure  in  order  to  pass  control  when  it  is  time  to 
generate  explanations.  Because  of  .Ada's  strong  support  of  OOP,  providing  this 
visibility  for  the  ES  shell  was  easily  done. 

With  respect  to  using  OC,  ’  in  designing  EFFESS,  the  operations  identified  for 
this  object  are  the  explanatory  Innctions  it  must  perform  and  are  described  in  the 
next  sectiini.  the  visibility  l:d- FESS  requires  consists  primarily  of  the  ES  shell's 
processing  package  and  its  KRS.  (V  isibility  was  also  established  to  a  useful  package 
of  I/O  routines.  However,  this  was  done  from  a  code  reusability  standpoint  and 
was  not  functionally  required),  .As  for  establishing  EFFESS's  external  interface,  the 


'IJ 

routiiu's  it  u.st“s  to  builfi  it'^  <‘\;<'('ut ion  trace  aiul  its  prcjCfssiiig  entry  procerliucs  lia\(- 
to  be  made  available  to  the  ES  shell. 

h  is  important  to  note  that  while  the  ES  shell  and  EEFESS  are  the  only  two 
objects  identitied  tor  this  compUte  ES  Development  Environnn  nf.  as  otlu'r  (;bjects 
are  developed  (i.e.  a  user  interface,  a  natural  language  processor,  etc.),  they  too  can 
be  easily  incorporated  into  the  system  using  this  sauie  procedure. 

11.3  Functionality 

In  looking  at  the  functional  requirements  of  EEEESS.  two  dithnent  ('.xplanation  en- 
\  ironrnents  were  identified;  the  ranlunt  environinem,  and  the  tnd-oj-pro(:e.>.iin(j  ow- 
vironment.  Interestingly,  the  e.xplanation  requirements  for  these  two  em’ironments 
arc  not  the  same.  V\'hile  they  do  share  several  of  the  same  reciuirements.  each  has 
some  unique  requirements  as  well.  For  e.xample.  during  the  runtime  environment  the 
user  rnav  be  [trornpted  for  information  needed  by  the  system.  Beitig  able  to  (wplain 
the  system  neecis  this  information  is  an  important  e.xplanation  recpiirement 
in  these  situations.  However,  the  end- of- processing  environment  has  no  reason  to 
prompt  the  user  for  information,  therefore  no  requirement  exists  for  a  WHh’  ex¬ 
planation  capability.  Conversely,  once  the  system  has  completed  its  processing  and 
arrived  at  some  kind  of  decision,  being  able  to  SHOW  the  criiicul  decision  path  (the 
sequence  of  rules  that  fired)  the  system  used  to  arrive  at  this  decision  provides  a 
great  deal  of  important  information.  However,  during  system  execution,  explaining 
the  current  decision  path  is  the  important  issue.  Therefore,  in  support  of  these 
difFerpnce.s.  EEFESS  provides  a  set  of  runtime  explanation  functions  and  a  set  of 
f  nd-of-processing  explanation  functions. 

•  Ffuritirne  Explanation  Functions 


1.  l-^rplnin  Rule  :  1  he  Explain  lUile  function  explains  the  iheiititied  rule  by 
displaying  its  contents  to  the  screen.  .\s  (iescri|jt  i\-e,  Euglish-lik('  naiuiiig 
couxentioris  were  used  ui  the  construction  of  the  rules,  no  additional  text 
generation  is  required  to  present  an  understandable  explanation. 

Explain  II The  Explain  Why  function  is  interpreted  to  mean.  Why' 
is  this  information  being  requested?  and  is  iJiesented  to  the  us<‘r 
as  an  option  whenever  the  user  is  prompted  lor  inloriuat ion.  1  he  l>asis 
tor  providing  this  explanation  is  twofold.  Eirst.  some  component  in  the 
>ystem  (i.e.  a  rule)  needs  this  information  in  order  tcj  cuiitimu'  processing. 
Second,  this  value  is  currently  unknown  and  couldn't  be  determined  via 
inheritance  or  message  passing.  Therefore,  EFFESS's  \VH\'  explanation 
identifies  the  slot  whose  value  is  being  requested,  the  frame  to  which  this 
slot  is  attached,  and  the  system  component  that  is  waiting  on  this  slot 
in  order  to  continue  processing. 

3.  Explain  How  :  The  Explain  How  function  is  interpreted  to  mean.  How 
did  the  system  arrive  at  this  point  in  its  processing?  and  uses  the 
execution  trace  to  provide  this  explanation.  'Fhis  function  starts  with  the 
first  rule  tested  by  the  system  and  recurses  through  the  execution  trace 
for  as  long  as  the  user  determines  is  necessary.  One  rule  from  the  trace 
is  explained  for  each  successive  HOW  request  the  user  provides.  He  can 
examine  the  entire  execution  trace  (from  the  start  rule  all  the  way  to  the 
current  rule  being  processed)  or  he  can  stop  at  whatever  level  he  is  com¬ 
fortable/satisfied  with.  The  explanation  content  for  each  rule  is  based  on 
the  specific  type  of  rule  it  is.  For  example,  rules  associated  with  OO.AL 
frames  are  chosen  for  execution  because  they  represent  the  specific  goal 
to  be  achieved.  I  herefore,  EFFESS's  HOW  function  explains  these  rules 


in  this  ('(nitt'Xt.  idi'iil  ifving  Uic  ruU-  nutulK'r.  i!u“  goal  lo  \h'  <i(lii<-\cil,  cti-. 
On  the  other  iiand,  rules  liiat  prompt  the  user  tor  information  are  ciiusen 
for  execution  because  the  system  needs  tliis  information  to  continue  pro¬ 
cessing.  Therefore,  these  rules  are  explained  with  respect  to  the  system 
component  that  is  dependent  on  them  for  tlie  needed  information. 

1.  Explain  U  hat  :  1  lie  Explain  What  function  is  intt'r]>reted  to  mean.  What 
is  the  value  of  slot  X?  and  is  available  for  use  t  hrouglioul  t  lie  e.xecut  ion 
of  tlie  system,  t  he  user  must  provide  tiie  name  of  an  attrilnite  ( slot )  and 
will  receive  its  corresponding  value  (or  a  not  foiuul  error  message)  in 
return.  Iliis  function  represents  one  type  ot  query  function  Firebaugli 
identihed  as  oneot  the  features  easily  supported  by  a  trame-basi'd  system. 

5.  E'xplain  Where  :  The  Explain  Where  function  is  interpreted  to  mean. 
Where  is  X  located  in  the  KRS?  and  is  used  to  explain  tlie  rela¬ 
tionships  of  objects  and  attributes  in  the  KB.  The  user  must  provitle 
an  object  name  or  an  attribute  name  and  will  receive  an  explanation  of 
who/what  the  input  item  is  related  too.  If  the  input  item  is  an  object, 
any  inheritance  relationships  to  other  objects  are  identified.  If  tlie  input 
item  is  an  attribute,  the  object  to  which  it  is  attaclied  is  identified.  I  bis 
function  rf'presents  a  .second  type  of  query  function. 

End-Of- Processing  Explanation  Functions 

4 

1.  Explain  Rule  :  same  as  in  runtime  functions 

2.  Explain  W'Tiat  :  same  as  in  runtime  functions 

d.  E'xplain  Where  :  same  as  in  runtime  functions 

1.  Show  CrtErnt  Pnth  ;  The  execution  trace  is  used  to  ;>rovide  tliis  function. 
.As  the  trace  maintains  the  correct  ordering  of  all  rules  tested  during  the 


s\stem's  execution,  the  critical  path  list  is  provided  l;y  simply  lumping 
through  the  execution  trace  and  printing  out  the  ride  numbers  (,if  the 
rules  whose  firtd  flag  has  been  set. 

d.  Show  Execution  Trace  :  This  function  also  uses  the  executimi  t  l  ace  to 
accomplish  it  function.  Its  purpose  is  to  display  the  entire  "eiiuence  ut 
rules  that  were  tested  during  the  system's  execution,  llowcoer.  a  rule  can 
be  in  one  of  three  states  during  various  stages  of  the  system  s  execution: 
pe (awaiting  information),  yfred  (its  antecedent  tested  truei.  ui  Jathd 
(its  antecedent  tesied  false).  Therefore,  this  lunctiiui  identilies  wliich 
state  a  particular  rule  is  in  at  the  various  stages  of  its  execuiioii. 

11.4  Functional  Framework 

In  analyzing  EFFESS  with  resoect  to  the  Functional  Framework  presented  in  (.'hap- 
tei  2.  we  find  that  Function  1.  Type  1  explanations  are  provided  by  the  HOW  lunc- 
tion.  the  SHOW  Critical  Path  function,  and  the  SHOW  Execution  Trace  function. 
3y  u.siug  a  stack  to  capture  the  execution  trace  of  the  system  (the  order  in  which 
the  rules  were  accessed),  the  basic  decision  process  of  the  system  is  identified,  lype 
2  explanations  are  provided  by  the  Rule,  What,  Where,  and  Why  functions,  all 
of  which  provide  information  about  the  elements  (objects  and  attributes)  in  the 
knowledge  base.  Function  1,  Fype  3  explanations  are  also  provided  to  a  limited  de¬ 
gree.  The  Why  function  can  identify  certain  instances  when  inheritance  or  message 
l)assing  has  been  used. 

f, f  f  f.SS  prcwidr-s  limited  Function  2  capabilities  by  allowing  the  user  to  rleter- 
muie  the  ilegree  of  ex|)lanation  jjrovided  by  the  HOW  function.  However,  as  the 
pnm-it'.  u-ers  et  Icf  f  FbS  are  assumed  to  be  system  designers  and  ki  nvledge  engi- 
•  e,  i-  '1,1 -.'ll  (III  the  previously  discussed  need  for  plug-in  test  and  debugging  type 
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'  M  , 

tho  ('.xplanat  ions  provided  in  this  system  have  lu'cii  dire(il\'  •;eare<l  he  i  hese 

users. 

Witti  respect  to  Function  d  caj)al)ilities,  FFFFSS  does  priA’ide  Finilish-like  oiit- 
[)iH  due  lo  the  descriptive  naming  conventions  used  in  the  system.  [{uAe\ ci'.  (me 
sidc'iahh'  romn  for  improvement  still  exists  in  this  area. 


Chapter  12 


EFFESS:  Conclusions  &:  Future 
Work 

12.1  Overview 

1  Ins  iliapU'i'  j.)r('sents  suinc  cuiicliKling  observati(jiis  .md  rciiiaiks  luiict.'niiiiii  ihr 
I'.I'FKSS  prijjt-'ct  and  considers  s(>veral  possible  directions  for  future  work.  In  <0 
dc)ing,  three  important  issues  are  disc'ussed:  the  use  of  .-\da  as  an  miplementati(;n 
lainmage  for  tliis  .\I  application,  the  positive  and  negative  aspects  o(  att(mif.if imi 
to  add  an  h.F  to  an  e.xisting  FS.  and  the  major  contributions  tliat  a  frame-basi'd 
system  pro\  ides  with  respect  to  generating  explanations. 

12.2  Conclusions 

12.2.1  A  Straightforward  Development  Process 

I  he  first  observation  or  conchision  about  this  project  is  that  its  devidopment  and 
irnr)lenientation  proved  to  be  a  much  more  .straightforward  process  than  originally 
anticipated.  This  is  due  to  three  major  factors;  the  use  of  the  OOP  design  method¬ 
ology,  the  nsf'  (;f  .Ada.  and  the  use  of  a  frame-based  F.S  shell. 

Fsing  the  OOP  design  ttielhodology  provided  several  contribttliotts  to  the  dexcl- 
opmetit  [trtncs.s.  Probably  the  most  influential  is  the  fact  that  tti  atialyzitig  the  FS 
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'ill'll  <i III  1  !  ill ■  I  iou'i'  t u  aild  an  1', !•  Icj  it  t  troin  an  ( )( )  1’  |)oi iil  ul  \  ii'w  i ,  i  'iii  >1 1 li  1 1  .  j!  ,i 
li'a^iMa  '1  lint  Kin  \^'as  nli'iit  iticil  to  tnak<' t  lit*  (Iccisn^n  to  at  t  cmiii  l  he  ciioi  t  in  i  lie  lii't 
[ilai'i'.  AiMit  ionally.  tho  ri'tinin'd  visibility  and  inlfrl'acr  bet utcii  Ml' I  i'lSS  and  ihf 
I'.S  'Ill'll  wi'i'i'  easily  identitied  using  this  design  met  liodolog\', 

(  liiM'ly  I'oiii.'led  with  the  cont  i'tl)nt  ions  OOP  priwided  to  the  de'iLiii  ul  h,  h  1 
re  the  euii!  nbut  ions  Ad.i  |n'o\'ided  in  su[)[)ort  ot  these  OOP  dec  i'ioiis.  Itiie  to  tin' 
-ilreadx'  identitied  relationship  that  exists  bi'tvvi'en  Ada  and  OOlh  once  the  \  isibi)it\ 
and  ml  ei  dice  'pc'cilications  had  Ijeen  estaitlished.  inijilc-meiit  iinr  iliein  in  .\da  'I'ra.'-  ,i 
'1  rtiiiiht  torw.'i  rd  process  using  the  built  it)  cuiilrncts  it  specificaliv  provides  lor  the',' 
pur|ioses  M.e,  with  ilanses.  pdrkiujt  ■••pf  .^ipctati  (inn  pihii  nm  itnil>.  eic.i. 

With  respect  to  t  he  Iraiiie-liased  KRS  Used  in  tin*  LS  shell,  maii'c  ol  iheiimtribm 
tioiis  this  structure  provides  for  explanation  generation  'vViU'e  descril;ed  in  ('hapier 
10.  I  hi'se  contrilnit i(nis  are  universal  in  nature,  in  that  they  are  provided  b\'  ;t 
Iranie-based  KRS  iriqilemented  in  any  language.  H  awever.  a  fraiiuu based  KRS  im- 
[demented  in  Ada  [Hwides  an  additional  contribution  to  e.xplanaf ion  generation  as 
a  result  of  its  strong  typing  requirements.  While  these  requirements  are  bi'inir 
identiliei.l  as  a  im  ior  contribution  to  t lie  develojmieni  of  Kf  f  fiSS.  it  is  interesting 
to  note  that  thesi*  same  requireniiuits  were  identitied  as  a  major  oljstacle  in  the 
develojunent  of  the  KS  shell  (see  [5.  (i’hapter  3]  for  complete  details).  In  an\'  i  ase. 
.\da  s  strong  typing  reijuired  the  dilFerent  objects  of  the  ES  .shell  to  be  decomposed 
into  dillerent  structures  ol  nested  reconls  and  record  i>olnlers  in  order  to  be  im|)le- 
meiited.  I'he  contribution  this  makes  to  F.FEESS  is  that  c'acli  of  the  ileco.uposed 
parts  of  an  object  are  available  for  explanation.  Therefore,  in  a  irame-fiased  KRS 
i in[)lemented  in  Ada,  a  hierarchical  decomposition  of  objects  at  two  dillerent  levels 
ol  abs*raction  are  available  for  explanation.  .At  tlie  kri oiclfdfjt  h  vfl  this  hierarchy  is 
[iiovided  bv  the  KRS.  .\t  'lie  nnpltnunfafion  li  cc/ this  hierarchy  is  provided  i)\'  the 


(lifFerenl  structuies  ut  nested  rt'cords  and  record  j)ointers  inentumed  ab(;ve. 

12.2.2  A  Plug-In  &  Unplug  Type  EF 

In  evaluating  how  successtul  we  were  in  accomplishing  our  ijht</-iu  KF  objective.  H\'o 
an  wer.s  are  required.  Overall,  the  effort  appears  to  be  a  succt'ss.  .Abscdutely  none  uf 
the  original  ES  shell  data  structures  were  changed  at  all  and  the  processing  routines 
were  only  changed  (added  to)  in  three  places;  in  the  routine  when'  the  e.Kecutiun 
trace  had  to  be  built,  in  the  routine  that  interfaced  with  the  user  so  as  to  gain 
access  to  EFFES.S.  and  in  the  driver  routine  to  provide  the  end  of  processing  e.\- 
planation  capabilities.  Due  to  .\da  s  st/M/'a/e  compilation  construct,  all  of  EFFE.SS' 
code  is  contained  in  one  .\da  package.  Therefore,  to  unplutj  EFFESS  from  the  ES 
shell  requires  commenting  out  or  removing  hfteen  lines  of  code  in  three  different 
routines  (see  .Appendi.x  C),  removing  the  EF  package  from  the  compilation  order, 
and  recompiling  the  ES  shell  code. 

Erom  an  explanation  standpoint  we  can  also  consider  EFFESS  a  success  in  that 
effective,  useful  explanations  are  provided,  especially  with  regards  to  Type  1  and 
Type  2  explanations.  However,  we  can  also  consider  EFFESS  to  be  only  marginally 
successful  because  of  its  limited  ability  to  produce  Type  3  explanations.  While  this 
is  true,  it  is  important  to  note  that  the  reason  Type  3  explanations  are  limited  is  not 
due  to  a  lack  of  explainable  information  but  rather  because  we  restricted  ourselves  to 
not  changing  any  (or  as  little  as  possible)  of  the  ES  shell  code.  Had  this  restriction 
not  existed,  several  Type  3  explanations  could  have  been  provided  liecause  informa¬ 
tion  concerning  inheritance,  message  passing,  and  the  forvvard/backward  chaining 
control  mechanisms  is  available  to  be  explained. 


12.2.3  Cost  versus  Capability 


In  many  \va\s.  the  entire  LFFESS  project  has  re-addressed  cjr  re-tocusi-d  our  atten¬ 
tion  on  a  \  er\'  old  and  important  issue  in  the  use  of  any  new  technology,  cost  versus 
('(ipnhtlttij.  Only  tiiute  amounts  ot  resources  (time,  money,  and  manpower)  e.xist  hu' 
any  given  project.  Often  times,  the  cost  of  incorporating  the  most  st at i  -oj-tht  -dii 
capabilities  a  technology  provides  e.xceeds  these  fin.ite  limits.  1  heretore.  clients  at 
idemt ifying  ways  to  provide  the  most  capability  for  the  least  amount  of  re¬ 
sources  are  not  only  justihed,  but  severely  needed.  This  project  has  been  one  id 
these  efforts.  However,  it  is  important  to  realize  that  a  frame-based  E.S  pro\  ides  the 
potential  for  producing  a  much  richer  explanation  capability  than  provirled  in  this 
project,  if  one  includes  the  recjuirements  and  speciheations  ol  an  FF  in  the  initial 
design  stages  of  the  ES.  The  following  section  identities  some  of  these  capabilities. 

12.3  Future  Work 

One  of  the  most  significant  discoveries  of  the  EFFESS  project  was  that  a  frame- 
based  KR.S  is  a  rich  structure  for  generating  explanations.  This  section  identities 
several  areas  of  future  work  intended  to  exploit  this  fact. 

12.3.1  KRS  Expansion 

W'e  have  already  pointed  out  that  virtually  everything  in  a  frame-based  system  is 
available  for  explanation.  Therefore,  if  the  frame-based  KRS  is  expanded  to  include 
more  information,  the  EF  that  uses  this  KRS  will  be  able  to  provide  expanded 
explanations.  Fikes  and  Kehler  [16]  provide  an  excellent  description  of  a  frame-based 
KRS  and  how  it  can  be  modified  to  provide  different  capabilities.  Thev  describe  a 
system  that  is  maile  up  of  frames,  slots,  facets,  and  subfacets.  I'ach  of  which  is  an 
attribute  of  the  preceding  object.  By  using  these  different  levels  of  attributes,  as 
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mill'll  ur  a>  littk'  rijn^lraiiiuiif /(ii-xTij)) ive  iiifurmat  iuii  l  aii  l>f  a ppropriat rl\'  idalfd 
to  any  item  in  the  KB.  For  ('xain[)l<'.  one  ciiiild  <tdd  farcts  to  a  slot  that  idi'iitihos 
the’  maxiimmi  and/or  miiiiinum  value’s  allowe-d  for  th;tt  slot.  ( 'oidideiice’  factors 
ide’iit  dying  the  de’gre’C'  of  certainty  or  reliahility  e)f  .i  sUrt  s  value  could  also  be  attached 
using  a  taceU.  It  one  were  to  ii'ni)Ienienl  the  rules  in  i  he  .system  as  frames  (something 
hike's  and  Ke'hler  eliscuss).  consielerahle  iidormalion  I'ould  be’  identifie-d  and  >tore’d 
tor  each  rule.  Historical  infe>rmatie>n  abe>ut  the’  elate  and  author  of  a  rule  could 
easily  be  stored.  So  coulel  English  translations  of  the  ride,  decscript ions  as  lu  the 
rule’s  importance  and  use,  reasons  why  a  rule  failed  to  fire.  etc.  .As  ean  I’asily  be 
see-n.  including  some  (or  all)  of  these  pieces  of  information  wouhl  ile’linitely  improve’ 
the  EF  of  the  system,  as  all  of  them  would  be  available  for  explanation. 

12.3.2  User  View 

Our  initial  effort  in  EFFESS  didn't  address  Function  2  issue's  to  any  significant 
degree.  However,  the  support  a  frame-based  system  could  provide  in  creating  a 
[.'str  Mew.  similar  to  the  one  Weiner  developed  in  BL.AH,  could  be  seen  as  EFFESS 
eleveloped.  For  example,  one  could  add  a  User  Identification  Slot  to  each  frame  in  the 
system,  indicating  the  degree  of  knowledge  the  user  had  concerning  that  jiarticular 
object,  and  then  provide  different  levels  of  explanation  of  that  object  based  on  the 
user's  knowledge  level.  Weiner’s  creation  of  two  separate  views  of  the  KB  could  also 
be  supported  by  a  frame-based  system,  using  the  object  relationship  identification 
capabilities  this  type  of  system  provides. 

12.3.3  Graphical  Display  of  KRS 

th’cause  ot  the  natural  identihcation  of  relationships  among  objects  provided  in 
a  frame-based  system,  being  able  to  display  these  relationships  in  gra()hical  form 
would  provide  a  tremendous  explanation  capability.  The  old  cliche  that  "a  picture 


is  worth  a  thousand  words  is  especially  true  when  one  is  ccndined  to  displavini; 
information  on  a  twenty-five  line  video  screen.  Being  limited  to  the  use  of  te.xtual 
descriptions  and  needing  to  keep  related  pieces  of  information  cm  the  screen  long 
enough  to  identify  the  importance  of  their  relationship,  is  very  difficult  to  do.  Draw¬ 
ing  pictures  to  show  these  relationships  is  a  much  more  effective  way  id'  picsenting 
the  information. 

12.3.4  Beginnings  of  a  Generic  Task 

Repeated  emphasis  has  been  given  to  the  rich  e.xplanation  generation  support  a 
frame- based  system  provides.  Interestingly,  if  we  step  back  and  look  at  the  total 
system  that  is  produced  by  EFFESS  (the  ES  shell  and  its  explanation  facilitv). 
we  can  see  the  definite  beginnings  of  an  environment  very  similar  to  one  of  Chan- 
drasekaran  s  generic  tasks.  Remembering  that  these  generic  tasks  are  intended  to 
provide  a  framework  that  unifies  three  major  areas  in  ESs:  the  probleni-solL'inij  pro¬ 
cess.  deep  cognitive  models,  and  explanation,  we  can  see  this  basic  framework  in 
EFFESS.  VVe  have  discussed  each  of  these  three  areas  with  respect  to  a  frame-based 
.system  during  our  previous  discussions,  but  have  not  tied  them  all  together  or  related 
them  to  Chandrasekaran's  work.  Our  system  provides  a  problem-solving  process  (a 
set  of  control  strategies)  with  its  forward  and  backward  chaining,  inheritance,  and 
message  passing.  While  our  system  doesn’t  presently  contain  any  deep  knowledge, 
the  mechanism  for  adding  it  to  the  system  has  been  identified  and  is  a  straightfor¬ 
ward  process  for  a  frame-based  system.  Our  system  has  a  basic  explanation  facility, 
and  while  it  is  currently  a  limited  one,  we  have  identified  the  fact  that  everything 
in  a  frame-based  KRS  is  available  for  explanation  and  therefore  expanding  our  EF 
into  a  more  robust  system  would  not  be  difficult.  The  only  thing  that  is  needed  is 
a  development  language  to  tie  this  all  together. 


Appendix  A 
EFFESS  Code 


- |**^t******^*Jt!***********=tt*»**^*****itc:*t^c*:tc:tc:(l****:4Ht*}(t**;(c****:tc*:(c***** 

- I  *♦♦***>[***  ;4c  *  :4c  «  :4i  :tc  :4c  iti  #  :4c 

--I**********  EXPLANATION  FACILITY  SPECIFICATION  ********** 

- I**********  :4c*****:4c:4c** 

- I**************************************************************** 

- I**************************************************************** 

- I**************************************************************** 


with  Frames,  Rules; 
package  Ef  is 

Procedure  Name:  CLEAR_EXECUTION_TRACE 
Inputs:  None 
Outputs:  None 

Purpose:  To  clear  or  re-initialize  the  execution  trace. 

Notes:  The  ES  shell  provides  a  menu  of  processing  options  upon 
completion  of  its  initial  execution.  Two  of  these  options 
allow  the  user  to  re-run  the  shell  with  the  same  knowledge 
base  file  or  with  a  different  knowledge  base  file.  If  either 
of  these  options  are  selected,  the  execution  trace  must  be  re¬ 
initialized.  Called  by  ES  shell  driver  progrsun.  Procedure 
SHELL . 


procedure  Clear_Execution_Trace; 


Procedure  Name:  ACCESS _RUNTIME_EF 
Inputs:  None 
Outputs:  None 

Purpose:  Provide  access  to  explanation  facility  during  execution 
of  the  ES  shell  (during  runtime) . 

Notes:  Called  by  Function  GET_USER_PROMPT  in  Package  USER.IO  of 
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--|  ES  shell. 


procedure  Access_Runtime_Ef ; 


Procedure  Name:  ACCESS_END_QF_PROCESSING_EF 
Inputs:  None 
Outputs:  None 

Purpose:  Provide  access  to  explanation  facility  after  the  ES 
shell  has  completed  execution. 

Notes:  Called  by  ES  shell  driver  program,  Procedure  SHELL. 

procedure  Access_End_Of _Processing_Ef ; 


Procedure  Name:  BUILD_EXECUTION_TRACE 

Inputs:  The  current  frame  being  accessed  by  the  ES  shell. 

The  current  rule  being  tested  by  the  ES  shell. 

Outputs:  None 

Purpose:  Builds  the  trace  of  the  ES  shell  execution  that  is  used 
by  the  explanation  facility  to  generate  many  if  its 
explanations . 

Notes:  Called  by  Procedure  FIRE.RULES  in  Package  DEMONS  of  the 
ES  shell. 


procedure  Build_Execution_Trace  (The.Frautie  : 

The.Rule 


in  Frames .Frame_Ptr; 
in  Rules . Rule_Ptr) ; 


Procedure  Neime:  SET_RULE_FIRED 

Inputs:  The  current  rule  just  fired  in  the  ES  shell. 

Outputs:  None 

Purpose:  Sets  appropriate  flags  in  trace  of  this  rule  to 
indicate  the  rule  has  been  fired. 

Notes:  Called  by  Procedure  FIRE_RULES  in  Package  DEMONS  of  the 
ES  shell. 


procedure  Set_Rule_Fired  (The_Rule  :  in  Rules . Rule_Ptr) ; 


Procedure  Name:  SET_RULE_FAILED 

Inputs:  The  current  rule  that  just  failed  to  fire  in  ES  shell. 
Outputs:  None 

Purpose:  Sets  appropriate  flags  in  trace  of  this  rule  to 
indicate  the  rule  has  failed  (didn't  fire); 

Notes:  Called  by  Procedure  FIRE_RULES  in  Package  DEMONS  of  the 
ES  shell. 


procedure  Set_Rule_Failed  (The.Rule  :  in  Rules . Rule_Ptr) 


end  Ef ; 


I 


—  spec 


-  -  \  ^^f:li:tf*****A‘***********’t‘ *********  ***-¥*****>^^f:^****y^**********ill^i**.*L* 

--  1  V^=r>f  V'tiJtt***  ********** 

—  I  **********  EXPLANATION  FACILITY  BODY  ****♦:»:»*** 


I  ***** 

-- 1  **********  ********** 
--|**:4c:4<**4.*:tc*************)f:**:***************ic***:tc******«***:t:*:****:4c4c* 

- \ **************************************************************** 

- I**************************************************************** 

with  Stack_Sequential_Bounded_Managed_Noniterative , 

Text_Io , 

Fraimes , 

Rules , 

User_Io ; 


package  body  Ef  is 

--  I  ********  ^<¥***********»****************************************** 
- I  *  :t(  i)ci)c  *  *  *  *  =tt***+i(t**** 

--(******+**♦  TYPE  DEFINITIONS  ♦*♦*****♦♦ 

--  I  ***:tl*:t<>tcitt**  t^t>(t***  +  *** 

-  -  I  ***********************************************;(<**************** 


t********* 


■|  Type  MENU_OPTIONS_TYPE  is  an  array  of  strings  containing  m- nu 
-|  options  used  in  displaying  a  particular  menu  to  the  screen. 

type  Menu_Options_Type  is 

array (Positive  range  <>)  of  Frames .New.String; 

-|  Type  EXEC_TRACE_TYPE  is  the  record  of  information  kept  for 
-|  each  rule  processed  by  the  ES  shell. 

type  Exec_Trace_Type ; 

type  Exec_Trace_Ptr  is  Access  Exec_Trace_Type ; 

type  Exec_Trace_Type  is 
record 


Curr_Frame 

Curr_Rule 

Pending 

Fired 

end  record; 


Frames .Frame_Ptr  :=  null; 
Rules . Rule_Ptr  :=  null; 
Boolean  ;=  True; 

Boolean  :=  False; 


--|:|c:4c**«**^**  **♦♦*♦*♦** 

-- 1  ******«;•<*«  PACKAGE  INSTANTIATIONS  ********** 

—  I  **********  ********** 


********** 


—  I  **************************************************************** 
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-|  Miscellaneous  instantiations  of  packages  needed  for  screen  I/O, 

package  Pos_Io  is  new 

Text_Io . Integer_Io(Positive) ; 
package  Rule.Io  is  new 

Text_Io . Integer_Io(Frames .Rule_No_Type) ; 
package  Bool_Io  is  new 

Text_Io  .Enuineration_Io  (Boolean)  ; 
package  Rule_0p_Io  is  new 

Text_Io . Enumeration_Io (Rules .Rule_Operator) ; 


-1  The  instantiation  of  the  generic  Stack  package,  creating  the 
-I  EXECUTION  TRACE. 

package  The_Execution_Trace  is  new 

Stack_Sequential_Bounded_Managed_Noniterative(Exec_Trace_Ptr) ; 


-I**********  ********** 


I  **********  ********** 

I**********  VARIABLE  DECLARATIONS  ********** 
I  **********  ********** 
I**************************************************************** 


-|  Declaration  of  the  size  of  the  execution  trace  stack. 
The.Size  :  Positive  :=  300; 


-|  Declaration  of  the  execution  trace  to  be  used  by  the  EF. 
Exec_Trace  ;  The_Execution_Trace . Stack(The_Size) ; 


■  I  **************************************************************** 
,|**********  ********** 
I**********  EXCEPTIONS  ********** 


-********** 


********** 


- 1  **************************************************************** 

-|  An  exception  that  is  raised  when  the  size  of  the  execution  trace 
-|  stack  is  not  large  enough. 

Ef _Fatal_Error  :  exception; 


I**********  ESTABLISH  VISIBILITY  ********** 
,|**********  ********** 
,  I**************************************************************** 


-|  Establish  the  visibility  of  different  FRAME  and  RULE  structures 


function  "="  (X,  Y  :  in 
renames  Rules. 
function  "="  (X,  Y  ;  in 
renames  Frames. 
function  "="  (X,  Y  :  in 
renames  Frames. 
function  "="  (X,  Y  :  in 
renames  Rules. 
function  "="  (X,  Y  :  in 
renames  Rules. 
function  "="  (X,  Y  :  in 
renames  Rules. 
function  "="  (X,  Y  ;  in 
renames  Frames. 
function  "="  (X,  Y  :  in 
renames  Frames. 
function  "="  (X,  Y  :  in 
renames  Frames. 
function  "="  (X,  Y  ;  in 
renames  Frames. 
function  "="  (X,  Y  :  in 
renames  Frames. 
function  "="  (X,  Y  :  in 
renames  Frames. 
function  "="  (X,  Y  ;  in 
renames  Frames. 


Rules . Rule_Ptr)  return  Boolecin 
Frames . Slot_Ptr)  return  Boolean 
Frames . Frame_Ptr)  return  Boolean 
Rules .Rule_Operand)  return  Boolean 
Rules . If _Token_Ptr)  return  Boolean 
Rules .Then_Token_Ptr)  return  Boolean 
Frames . Frame_List_Ptr)  return  Boolean 
Frames . Frame _Name)  return  Boolean 
Frames  .  Frame_Type)  return  Boolecin 
Frames . Slot_Name)  return  Boolean 
Frames . Parent_Ptr)  return  Boolean 
Frames . Demon_Ptr)  return  Boolean 
Frames .Rule_List_Ptr)  return  Boolean 


***4c;4c***]tc*  UTILITY  ROUTINES  ***♦**♦♦♦* 

Subroutine  Name:  WAIT 
Inputs:  None 
Outputs:  None 

Purpose:  Provide  control  of  screen  output.  Allows  user  to  view 
information  presented  to  the  screen  without  it  scrolling  by. 
Notes:  None 


procedure  Wait  is 
X  :  StringCl  .  .  2)  ; 

Y  :  Natural; 
begin 

Text_Io . New_Line ; 

Text_Io .Put("  (Press  <return>  to  continue)"); 
Text_Io . Get_Line(X ,Y) ; 

Text_Io . Skip_Line; 


Text_Io .New_Line(2) ; 
end  Wait; 


Subroutine  Naime :  FIND_TRACE_DATA 
Inputs:  The  current  rule  being  processed  by 
Outputs:  Pointer  to  trace  record  of  current 
Purpose:  Search  execution  trace  for  current 
appropriate  flags  can  be  updated. 

Notes:  None 


the  ES  shell, 
rule . 

rule  so  that 


function  Find_Trace_Data  (The_Rule  :  in  Rules . Rule_Ptr) 

return  Exec_Trace_Ptr  is 
Temp_Data  :  Exec_Trace_Ptr ; 

Temp_Trace  :  The_Execution_Trace . Stack(The_Size) ; 
begin 

The_Execution_Trace.Copy(Exec_Trace,  Temp_Trace) ; 
while  not  The_Execution_Trace.Is_Empty(Teinp_Trace)  loop 
Temp_Data  :=  The_Execution_Trace .Top_0f (Temp_Trace) ; 
if  Temp_Data.Curr_Rule.Rule_No  =  The_Rule . Rule_No  then 
return  Temp_Data; 
end  if ; 

The_Execution_Trace .Pop(Temp_Trace) ; 
end  loop; 

end  Find_Trace_Data; 


Subroutine  Name:  PRINT_A_RULE 

Inputs:  The  rule  whose  contents  are  to  be  printed. 

Outputs:  The  contents  of  the  input  rule. 

Purpose:  Print  the  contents  of  a  rule  to  the  screen  in  user 
readable  format . 

Notes:  None 


procedure  Print _A_Rule  (The_Rule  :  in  Rules . Rule_Ptr)  is 
Temp_Rule  :  Rules . Rule_Ptr  :=  The_Rule; 

Temp.Ante  :  Rules . If _Token_Ptr; 
begin 

if  Temp_Rule . Antecedent  =  null  then 
Temp_Ante  :=  null; 
else 

Temp_Ante  :=  new  Rules . If _Token; 

Temp_Ante . all  :=  Temp _Rule . Antecedent . all ; 
end  if; 

User_Io . Print _Rule_No (Temp _Rule . Rule_No) ; 

Text_Io .New.Line; 

Text_Io .Put("If ")  ; 
if  Temp_Ante  =  null  then 
Text_Io . Set_Col(5) ; 

Text.Io. Put ("TRUE  Then"); 

Text_Io . Set_Col(30) ; 

Text_Io . Put ("--  since  this  rule  has  no  antecedent"); 


Text_Io . New_Line ; 
else 

while  Temp_Ante  /=  null  loop 
Text_Io . Set_Col(5)  ; 

User_Io . Print_Operand(Temp_Ante . Operand_l) ; 
Text_Io.Put("  "); 

Rule_0p_Io . Put (Temp_Ante . Operator) ; 

Text_Io  Put ("  ")  ; 

User_Io . Print_Qperand(Temp_Ante . 0perand_2) ; 
if  Temp _ Ant e . Next  =  null  then 
Text_Io .PutC"  Then"); 
else 

Text_Io . Put ("  And"); 
end  if ; 

Text_Io . New_Line ; 

Temp_Ante  :=  Temp.Ante .Next ; 
end  loop; 
end  if; 

Text.Io . New_Line ; 

User_Io . Print_Consequent(Temp_Rule .Consequent) ; 
end  Print_A_Rule; 


I  Subroutine  Name:  FIND_SUB_FRAMES 

I  Inputs;  The  name  of  the  frame  whose  sibling  frames  are  wanted. 

I  Outputs:  A  list  of  pointers  to  all  frame(s)  subordinate  to  input 
I  frame,  (possibly  empty) 

I  Purpose;  Search  active  frames  list  for  all  frames  having  input 
I  frame  name  identified  as  one  of  their  parents. 

I  Notes:  None 

function  Find_Sub_Frames  (The_Name  :  in  Frames . Frame _Name) 

return  Frames . Frame_List_Ptr  is 
The_Frames  ;  Frames . Frame_List_Ptr ; 

Head,  Prev,  Curr  :  Frames .Frame_List_Ptr; 

Is_Head  :  Boolean  :=  True; 

Temp.Parants  :  Frames . Parent _Ptr; 
begin 

The_Frames  :=  Frames . Active.Frames ; 
while  The_Frames  /=  null  loop 

Temp_Parents  ;=  The_Frames .This_Frame . Parents ; 
while  Temp_Parents  /=  null  loop 

if  Temp_Parents . Parent _Name  =  The_Name  then 
if  Is_Head  then 

Head  ;=  new  Frames . Frame_List ; 

Head . This_Frame  :=  The_Frames .This_Frame ; 

Prev  :=  Head; 

Is_Head  :=  False; 
else 

Curr  :=  new  Fraimes  . Frame _List ; 

Curr . This .Frame  ;=  The.Frames .This.Frame ; 

Prev. Next  :=  Curr; 


Prev  :=  Curr; 
end  if ; 
end  if; 

Temp_Parents  :=  Temp_Parents . Next ; 
end  loop; 

The_Frames  :=  The_Frames .Next ; 
end  loop; 
return  Head; 
end  Find_Sub .Frames ; 


I  Subroutine  Name:  PRINT.PARENT.OF.INFO 
I  Inputs:  A  pointer  to  the  "parent"  frame. 

I  Outputs:  The  names  of  any/all  sibling  frames. 

1  Purpose:  Identify  the  frames  for  which  the  input  frame  is 
I  a  parent.  If  there  are  none,  output  appropriate  message  ... 

I  otherwise  print  the  sibling  frame  name(s) . 

I  Notes :  None 

procedure  Print.Parent.Of .Info 

(The. Object  ■  in  Frames . Frame. Ptr)  is 
Temp. Object  :  Frames . Frame.Ptr  ;=  The.Object; 

Parent. Of .List  :  Frames .Frame.List. Ptr ; 
begin 

Parent.Of .List  :=  Find.Sub.Frames (Temp.Obj ect . Name) ; 
if  Parent.Of .List  =  null  then 

User.Io . Print. Frame. Name (Temp.Obj  ect .Name) ; 

Text. lo . Put ("  has  no  sub-class  object(s)  related  to  it."); 
Text. I 0 . New. Line ; 

Text.Io . Put ("  (  ")  ; 

User.Io . Print.Frame.Name (Temp.Obj ect . Name) ; 

Text.Io . Put ("  IS  not  a  parent  of  any  other  object(s)  )"); 
Text.Io . New. Line ; 
else 

User.Io . Print. Frame .Name (Temp .Object . Name) ; 

Text.Io . Put ("  IS  the  parent  of  "); 
if  Parent.Of .List . Next  =  null  then 

User.Io . Print. Frame.Naane(Parent. Of .List . This. Frame . Name) ; 
else 

while  Parent.Of .List  /=  null  loop 
Text.Io .New. Line; 

Text.Io .Set. Col (5) ; 

User.Io . Print.Frame.Name (Parent. Of .List .This. Frame . Name) ; 
Parent.Of .List  :=  Parent.Of .List . Next ; 
end  loop; 
end  if; 

Text.Io . New.Line ; 
end  if; 

end  Print.Parent.Of .Inf o ; 


I  Subroutine  Name:  PRINT.MEMBER.OF.INFO 


I  Inputs:  A  pointer  to  the  frame  in  question. 

t  Outputs:  The  frame  ncunes  of  any/all  "parents''  of  input  frame. 

I  Purpose:  Identify  the  parent  frames  of  the  input  frame  and  print 
I  them  to  screen.  If  there  are  none,  output  appropriate  message 
I  ...  otherwise  print  the  frame  name(s)  of  the  parents. 

I  Notes :  None 

procedure  Print_Member_Of _Inf o 

(The.Object  :  in  Frames . Frame_Ptr)  is 
Temp_Object  :  Frames . Frame_Ptr  :=  The.Dbject; 
begin 

if  Temp.Object . Parents  =  null  then 

User_Io . Print _Frame_Name (Temp .Object . Name) ; 

Text.Io . Put 

("  is  not  a  sub-class  object  of  a  higher  class  object.''); 
Text.Io . New.Line ; 

Text.Io . Put ("  (  ")  ; 

User.Io . Print_Frame_Name(Temp_Object .Name) ; 

Text.Io  .  Put  (''  has  no  parent(s)  )"); 

Text.Io . New .Line ; 
else 

User.Io . Print. Frame. Name (Temp. Object . Name) ; 

Text.Io . Put ("  IS  a  sub. class  object  of  ") ; 
if  Temp. Obj ect . Parents . Next  =  null  then 

User.Io . Pr int. Frame .Name (Temp. Ob j  ect . Parents . Parent .Name) ; 
else 

while  Temp. Obj ect . Parents  /=  null  loop 
Text.Io .New.Line; 

Text.Io . Set.Col (5) ; 

User.Io  .Print_FraLme.Name(Temp.Object  .Parents  .  Parent  .Name)  ; 
Temp.Obj ect .Parents  :=  Temp.Obj ect .Parents .Next ; 
end  loop; 
end  if; 

Text.Io . New.Line ; 
end  if; 

end  Print .Member. Of .Inf o ; 


I  Subroutine  Name:  FIND. OBJECT 
I  Inputs:  The  name  of  a  frame. 

1  Outputs:  Pointer  to  frame  record  of  input  frame  name. 

I  Purpose:  Search  the  active  frames  list  for  the  frame  name  input 
I  and  return  its  record  of  information  if  found. 

I  Notes:  None 

function  Find. Object  (The. Name  :  in  Frames . Frame. Name) 

return  Frames . Frame. Ptr  is 
The. Frames  :  Frames . Frame. List. Ptr ; 
begin 

The.Frames:=  Fraimes .  Active.Frames ; 
while  The. Frames  /=  null  loop 

if  The. Fraimes  .This. Frame -Name  =  The.Name  then 


return  The_Frames .This.Frame , 
else 

The.Frames  ;=  The .Frames .Next ; 
end  if ; 
end  loop; 
return  null; 
end  Find.Object; 


-|  Subroutine  Name:  FIND.ATTRIBUTE 
-|  Inputs:  The  name  of  an  attribute  (slot). 

-|  Outputs:  Pointer  to  frame  containing  the  input  attribute  name. 
-|  Purpose:  Find  the  frame  containing  the  attribute  identified. 

-|  Notes:  Searches  all  slot  pointers  of  each  frame  in  active  list 
-1  looking  for  a  match  to  the  input  name. 

function  Find.Attribute  (The.Name  :  in  Frames . Slot.Name) 

return  Frames . Frame.Ptr  is 
The.Frames  :  Frames . Frame_List_Ptr ; 

The.Slot  :  Frames . Slot.Ptr; 
begin 

The_Frames:=  Frames . Active.Frames ; 
while  The.Frames  /=  null  loop 

The.Slot  :=  Frames . Find.Slot (The.Frames . This.Frame ,  The.Name) 
if  The.Slot  /=  null  then 

return  The.Frames .This.Frame ; 
else 

The.Frames  :=  The .Frames . Next ; 
end  if ; 
end  loop; 
return  null; 
end  Find.Attribute ; 


Subroutine  Name:  FIND.R''uE. ATTRIBUTE 
Inputs:  An  execution  trace  record  pointer. 

Outputs:  Pointer  to  a  slot  record. 

Purpose:  Given  a  rule  number  (contained  in  the  execution  trace 
record),  find  the  slot  related  to  this  rule  number. 

Notes:  None 


function  Find.Rule.Attribute  (The.Data  :  in  Exec.Trace.Ptr) 

return  Frames . Slot. Ptr  is 
Temp. Data  :  Exec.Trace.Ptr  ;=  The.Data; 

Temp.Slot  :  Frames . Slot. Ptr ; 

Temp.Demon  :  Frames . Demon. Ptr ; 

Temp.Rules  :  Frames . Rule.List.Ptr ; 
begin 

Temp.Slot 


Temp.Slot  :=  Temp. Data. Curr. Frame . Slots ; 
while  Temp.Slot  /=  null  loop 
Temp.Demon  :=  Temp.Slot . Demons ; 
while  Temp.Demon  /=  null  loop 


Temp_Rules  :=  Temp_Demon . Rules ; 
while  Temp_Rules  /=  null  loop 

if  Temp_Rules . Rule_No  =  Temp_Data . Curr_Rule . Rule_No  then 
return  Teinp_Slot; 
end  if ; 

Temp_Rules  :=  Temp_Rules . Next ; 
end  loop; 

Temp_Demon  :=  Temp_Demon . Next ; 
end  loop; 

Terap.Slot  :=  Temp_Slot . Next ; 
end  loop; 

end  Find_Rule_Attribute ; 


Subroutine  Name:  PRINT_HOW_HEADER 

Inputs:  The  rule  number  currently  being  explained. 

Outputs:  HOW  header  information. 

Purpose:  Output  header  information  for  the  HOW  explanation 
function . 

Notes:  None 


procedure  Print _How_Header 

(The_Rule_Number  :  in  Frames . Rule_No_Type)  is 
The.Num  :  Frames .Rule_No_Type  :=  The_Rule_Number ; 
begin 

Text_Io . Set.Col (7) ; 

Text.Io . Put 

("Currently  Explaining  HOW  The  System  Decided  To") ; 
Text.Io . Put 
("  Process  Rule  #") ; 

Ru!"  e_Io  .  Put  (The_Num,  3); 

Text _Io . New_Line (2) ; 
end  Print _How_Header ; 


Subroutine  Name:  PRINT_GOAL_RULE_INFO 
Inputs:  An  execution  trace  record. 

Outputs:  Explanation  of  HOW  the  system  processed  this  rule. 
Purpose:  Explain  HOW  the  system  decided  to  process  this  rule 
(contained  in  the  execution  trace  record)  if  this  rule  is 
associated  with  a  GOAL  type  frame. 

Notes:  None 


procedure  Print _Goal_Rule_Info  (The.Data  :  in  Exec_Trace_Ptr)  is 
Temp.Data  :  Exec_Trace_Ptr  :=  The.Data; 
begin 

Print_How_Header (Temp_Data .Curr_Rule .Rule_No) ; 

Text_Io .Put("Rule  #"); 

Rule_Io .Put (Temp _Data.Curr_Rule-Rule_No,  3) ; 

Text„Io  .Put("  IS  associated  with  the  Goal  Fraime  =  ")  ; 

User.Io . Pr int_Frame_Name (Temp .Data .Curr .Frame .Name) ; 

Text.Io .New.Line; 


Text_Io . Put 

("Attempting  to  determine  a  Goal  Value  for  Attribute  =  "); 
User.Io . Print _Operand(Temp_Data.Curr_Rule .Consequent .Target) 
Text_Io .New_Line; 

Text_Io . Put("This  value  is  to  be  obtained  by  ") ; 
case  Temp_Data. Curr_Rule. Consequent .Source .Operand_Kind  is 
when  Rules . Local_Slot  =>  Text_Io .Put("Inheritance  from  "); 
when  Rules . Dist_Slot  =>  Text_Io . Put ("Message  to  "); 
when  others  =>  null; 
end  case; 

Text_Io . Put ("Attribute  =  ") ; 

User.Io . Print _Operand(Temp_Data . Curr_Rule . Consequent . Source) 
Text_Io .New_Line; 
end  Print _Goal _Rule_Inf o ; 


Subroutine  Name;  PRINT_START_RULE_INFQ 
Inputs:  An  execution  trace  record. 

Outputs:  Explanation  of  HOW  the  system  processed  this  rule. 
Purpose:  Explain  HOW  the  system  decided  to  process  this  rule 
(contained  in  the  execution  trace  record)  if  this  rule  is 
associated  with  a  START  type  frame. 

Notes :  None 

procedure  Print _Start_Rule_Info  (The.Data  :  in  Exec.Trace.Ptr) 
Temp_Data  :  Exec_Trace_Ptr  :=  The_Data; 
begin 

Print _How_Header (Temp _Data.Curr_Rule .Rule_No) ; 

Text.Io . Put("Rule  #") ; 

Rule_Io . Put (Temp_Data . Curr_Rule . Rule_No ,  3) ; 

Text_Io . Put ("  is  associated  with  the  Start  Frame  =  "); 
User_Io . Print _Frame_Name(Temp_Data.Curr_Frame .Name) ; 

Text_Io . New_Line ; 

Text_Io . Put_Line 

("Using  initial  information  this  freime  provides,  begin"); 
Text_Io . Put ("processing  by  attempting  to  determine  a  ") ; 
Text.Io . Put ("Value  for  "); 

User_Io . Print _Qperand(Temp_Data.Curr_Rule .Consequent .Target) 
Text_Io . New.Line ; 

Text_Io . Put("This  value  is  to  be  obtained  by  ") ; 
case  Temp_Data.Curr_Rule .Consequent . Source . Operand_Kind  is 
when  Rules .Local_Slot  =>  Text_Io . Put ("Inheritance  from  "); 
when  Rules . Dist_Slot  =>  Text_Io . Put ("Message  to  ") ; 
when  others  =>  null; 

end  case; 

Text_Io  .PutC'attribute  "); 

User_Io . Pr int_0per and (Terap_Dat a. Curr_Rule .Consequent . Source) 
Text_Io . New_Line ; 
end  Print_Start_Rule_Inf o ; 


I  Subroutine  Name:  PRINT_PROMPT_RULE_INFO 


I  Inputs:  An  execution  trace  record. 

I  Outputs;  Explanation  of  HOW  the  system  processed  this  rule. 

1  Purpose:  Explain  HOW  the  system  decided  to  process  this  rule 
I  (contained  in  the  execution  trace  record)  if  this  rule  is  a 
I  PROMPT  type  rule . 

I  Notes:  None 

procedure  Print _Prompt_Rule_Info  (The.Data  ;  in  Exec_Trace_Ptr ; 

The.Trace  :  The_Execution_Trace . Stack) 
Curr_Data  :  Exec_Trace_Ptr  :=  The_Data; 

Pending_Data  :  Exec_Trace_Ptr ; 

Temp_Trace  :  The_Execution_Trace . Stack(The_Size) ; 
begin 

The_Execution_Trace . Copy(The_Trace ,  Temp_Trace) ; 
while  not  The_Execution_Trace . Is_Empty (Temp_Trace)  loop 
Pending_Data  :=  The_Execution_Trace .Top_0f (Temp_Trace) ; 
if  Pending_Data. Pending  then 
exit  ; 
end  if ; 

The_Execution_Trace . Pop(Temp_Trace) ; 
end  loop; 

Text _Io . Put ( "Rule  #")  ; 

Rule_Io . Put (Pending_Data. Curr_Rule .Rule_No ,  3) ; 

Text_Io . Put ("  is  related  to  Rule  #") ; 

Rule_Io . Put(Curr_Data.Curr_Rule . Rule.No ,  3) ; 

Text.Io .New_Line(2) ; 

Text.Io. Put ("Rule  #"); 

Rule.Io . Put (Pending_Data. Curr_Rule .Rule_No ,  3) ; 

Text.Io .Put("  is  in  'pending'  status  awaiting  a  value  for  "); 
User.Io . Pr int .Operand (Curr.Dat a. Curr .Rule . Consequent . Target) ; 
Text.Io . New_Line(2) ; 

Print .A. Rule (Pending. Data . Curr.Rule) ; 

Text.Io .New.Line(2) ; 

Text.Io .Put ("Remember  ...  Rule  #") ; 

Rule.Io . Put (Curr.Data . Curr.Rule . Rule. No ,  3) ; 

Text.Io . Put("  prompts  for  a  value  for  "); 

User.Io . Print .Operand (Curr.Data. Curr.Rule . Consequent . Target) ; 
Text.Io . New. Line (2) ; 
end  Print .Prompt.Rule. Inf o; 


I  Subroutine  Name:  PRINT.STANDARD.RULE.INFO 
I  Inputs:  An  execution  trace  record. 

I  Outputs:  Explanation  of  HOW  the  system  processed  this  rule. 

I  Purpose:  Explain  HOW  the  system  decided  to  process  this  rule 
I  (contained  in  the  execution  trace  record)  if  this  rule  is  a 
1  LOCAL. SLOT  or  DIST.SLOT  type  rule. 

I  Notes :  None 

procedure  Print.Standard.Rule.Inf o 

(The. Data  :  in  Exec.Trace.Ptr)  is 
Temp. Data  ;  Exec.Trace.Ptr  :=  The. Data; 


Curr_Attrib  :  Frames . Slot_Ptr ; 
begin 

Curr_Attrib  :=  Find_Rule_Attribute(Temp_Data) ; 

Print _How_Header(Temp_Data.Curr_Rule . Rule_No) ; 

Text _Io . Put ("Attempting  to  determine  value  for  Attribute  =  "); 
User_Io . Print _Slot_Name(Curr_Attrib . Name) ; 

Text_Io . New_Line ; 

Text.Io. Put ("Rule  #"); 

Rule_Io . Put (Temp_Data.Curr_Rule .Rule_No ,  3) ; 

Text_Io . Put("  is  one  of  the  rules  that  attempts  to  do  this"); 
Text_Io .New_Line(2) ; 

Print_A_Rule(Temp_Data. Curr_Rule) ; 

Text_Io . New_Line ; 
end  Print_Standard_Rule_Inf o : 


Subroutine  Name;  EXPLAIN_TQP_OF_TRACE 
Inputs;  The  top  record  on  the  execution  trace  stack. 

The  remainder  of  the  execution  trace  stack. 

Outputs;  None 

Purpose;  Determine  what  type  of  rule  is  on  the  top  of  the 

execution  trace  and  call  the  appropriate  procedure  to  explain 
HOW  this  type  of  rule  was  processed. 

Notes;  None 

procedure  Explain_Top_Of .Trace  (The.Top  ;  in  Exec_Trace_Ptr ; 

The.Trace  ;  in  out  The_Execution_Trace. Stack)  is 
Temp.Top  ;  Exec_Trace_Ptr  ;=  The.Top; 
begin 

Text.Io .New_Line(5) ; 

if  Temp.Top . Curr.Frame . F.Type  =  Frames. Goal  then 
Print_Goal_Rule_Inf o(Temp_Top) ; 
elsif  Temp_Top.Curr_Frame.F_Type  =  Frames. Start  then 
Print_Start_Rule_Info (Temp.Top) ; 
elsif  Temp _Top.Curr_Rule. Antecedent  =  null  and  then 

Temp.Top . Curr.Rule . Consequent . Source . Operand.Kind  = 

Rules. Prompt  then 

Print_How_Header(Temp_Top.Curr_Rule .Rule.No) ; 
Print_Prompt_Rule_Info(Temp_Top,  The.Trace) ; 
elsif  Temp _Top . Pending  then 

Pr int .Standard .Rule _Info (Temp _Top) ; 
end  if; 

end  Explain.Top.Of .Trace; 


Subroutine  Name;  PRINT.STACK .TO. SMALL 
Inputs;  None 

Outputs;  An  error  message. 

Purpose;  Print  an  appropriate  error  message  if  the  execution 
trace  stack  is  not  large  enough  to  hold  all  of  the  necessary 
trace  records . 


-1  Notes:  None 


procedure  Print „Stack_To_Small  is 
begin 

Text_Io .New_Line(30) ; 

Text_Io . Set_Col (27) ; 

Text_Io . Put_Line("*****  FATAL  ERROR  ****=*<"); 

Text_Io . Set_Col (20) ; 

Text_Io . Put_Line("Stack  size  for  Execution  Trace  to  small."); 
Text_Io . Set_Col (30) ; 

Text_Io . Put ("Current  size  =") ; 

Pos.Io . Put (The_Size,  5); 

Text_Io .New_Line; 

Text_Io . Set_Col ( 14) ; 

Text_Io . Put_Line 

^"To  correct,  increase  THE_SIZE  in  package  body  of  EF  "); 
Text_Io . Set_Col(38)  ; 

Text_Io . Put_Line("and") ; 

Text_Io . Set_Col (29)  ; 

Text_Io . Put_Line ("Recompile  the  system."); 

Text.Io . New_Line(6)  ; 
raise  Ef _Fatal_Error ; 
end  Print_Stack_To_Small ; 
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Subroutine  Name:  FIND.LONGEST.OPTION 
Inputs:  An  array  of  menu  option  strings. 

Outputs:  The  length  of  the  longest  string  in  the  array. 

Purpose:  Determine  length  of  longest  option  for  a  particular 
menu . 

Notes:  Used  to  center  the  menu  on  the  screen,  when  it  is 
displayed. 


function  Find_Longest_Option 

(The.Array  :  in  Menu_Options_Type)  return  Positive  is 
Longest  :  Positive  :=  1; 
begin 

for  I  in  The .Array ' range  loop 

if  The.Array (I) .The .Length  =  0  then 
exit ; 

elsif  The.Arrayd)  .The.Length  >  Longest  then 
Longest  :=  The.Arrayd)  .The.Length; 
end  if ; 
end  loop; 
return  Longest ; 
end  Find.Longest.Option; 


I  Subroutine  Name:  DISPLAY_A_MENU 
I  Inputs:  An  array  of  menu  option  strings. 

I  The  total  number  of  strings  input. 

I  Outputs:  Numeric  value  of  menu  option  selected  by  the  user. 

I  Purpose:  Print  a  menu  to  the  screen  and  get  the  desired  option 
I  selected  by  the  user. 

I  Notes:  The  menu  is  centered  on  the  screen  (assumes  80  char  wide 
I  screen).  Error  checking  on  user  selection  performed.  Illegal 
I  values  aren't  accepted.  User  is  re-prompted  for  another 
I  selection  if  previous  selection  was  invalid. 

function  Display_A_Menu 

(The_Qptions_List  :  in  Menu_Options_Type ; 

Max_Qptions  :  in  Positive)  return  Positive  is 
Title_Qffset  :  Integer  :=  0; 

0ptions_0f f set  :  Integer  :=  0; 

Longest_Qption  :  Positive  := 

Find_Longest_Option(The_Dpt lons.List) ; 

Choice  :  Positive  :=  1; 
begin 

Text_Io .New_Line(2) ; 

Title_Qffset  :=  (80  -  The_Options_List ( l) . The_Length) /2 ; 
Options.Qf f set  :=  (80  -  Longest_0ption) /2 ; 

Text.Io . Set _Col (Text _Io .Positive .Count (Title.Of f set) ) ; 

Text.Io . Put(The_0ptions_List(l) .The.String 

(1  ..  The.Options.List ( 1) . The.Length) ) ; 

Text.Io .New_Line(2)  ; 

for  I  in  2  . .  Max.Options  +  1  loop 

Text.Io . Set _Col (Text _Io . Positive.Count (Options.Off set) ) ; 
Text.Io . Put (The.Opt lons.List (I) . The .String 

(1  ..  The.Options.List(I) .The.Length)) ; 

Text.Io . New.Line ; 
end  loop; 

Text.Io . New.Line ; 
loop 
begin 

Text.Io . Set. Col (Text.Io . Positive. Count (Options.Of f set) ) ; 
Text.Io . Put ("  enter  desired  option:"); 

Pos.Io .Get(Choice) ; 
if  Choice  >  Max. Options  then 

Text.Io . Put. LineC'Invalid  Option!  Please  Try  Again."); 
Text.Io . Skip.Line ; 

Text.Io .New.Line; 
else 
exit ; 
end  if ; 
exception 

whan  Text.Io .Data.Error  => 

Text.Io .New.Line ; 

Text.Io . Put _Line("Invalid  Option!  Please  Try  Again."); 


rjo 


Text_Io . Skip.Line ; 

Text_Io.New_Line; 

end ; 

end  loop; 
return  Choice; 
end  Display_A_Menu ; 

Subroutine  Name:  SETUP_CONTINUE_HOW_MENU 
Inputs:  None 

Outputs:  Array  of  options  for  the  Continue  Explaining  How  menu. 
Purpose:  Input  the  menu  options  text  for  the  Continue  Explaining 
How  menu . 

Notes:  The  HOW  explanation  cam  be  repeated  as  often  as  the  user 
needs.  These  menu  options  provide  the  user  this  capability. 

function  Setup_Continue_How_Menu  return  Menu_Options_Type  is 
Opts  :  Menu_Options_Type(l  . .  5) ; 
begin 

Opts ( 1) . The_String(l  ..  35)  := 

"*****  Continue  Explaining  HOW  *♦***"  ; 

Opts(l) .The.Length  :=  35; 

Qpts(2) .The_String(l  ..  o6)  := 

"1)  CONTINUE  How  Explanation  Process"; 

Opts (2) . The_Length  :=  36; 

0pts(3) .The_String(l  ..  32)  := 

"2)  EXIT  How  Explanation  Process"; 

0pts(3) .The.Length  :=  32; 
return  Opts; 

end  Setup _Continue_How_Menu; 


Subroutine  Name:  SETUP _ACCESS_TO_EF .MENU 
Inputs:  None 

Outputs:  Array  of  options  for  the  Access  EF  menu. 

Purpose:  Input  the  menu  options  text  for  the  Access  EF  menu. 
Notes:  These  options  provide  the  user  with  runtime  access  to  amd 
from  the  explanation  facility. 


function  Setup.Access.To.Ef .Menu  return  Menu.Options.Type  is 
Opts  :  Menu.Options.Typed  ..  5); 
begin 

Opts(l) .The_String(l  ..  26)  :=  USER  OPTIONS  ****♦"; 

Opts(l) .The.Length  :=  26; 

0pts(2)  .The.Stringd  ..  23)  :=  "1)  Request  Explanation"; 

Opts (2) .The.Length  :=  23; 

0pts(3) .The_String(l  ..  30)  :=  "2)  Provide  Response  To  Prompt"; 
Opts (3) .The.Length  :=  30; 
return  Opts; 

end  Setup.Access.To.Ef .Menu; 


Subroutine  Name:  SETUP _MAIN.OPTIONS_MENU 
Inputs:  None 

Outputs:  Array  of  options  for  the  Main  Explanation  menu. 
Purpose:  Input  the  menu  options  text  for  the  Main  Explanation 
menu . 

Notes:  These  options  identify  the  main  runtime  explanation 
functions  available  to  the  user. 


function  Setup _Main_Qptions_Menu  return  Menu_Options_Type  is 
Opts  :  Menu_Options_Type(l  ..  7); 
begin 

Opts(l) .The_String(l  ..  41)  := 

"*****  RUNTIME  EXPLANATION  OPTIONS  *♦***"; 

Opts(l) .The_Length  :=  41; 

Opts (2) . The_String(l  ..  56)  := 

"1)  SHOW  RULE  (show  the  contents  of  an  individual  rule)."; 
0pts(2) .The_Length  :=  56; 

Qpts(3) .The_String(l  ..  48)  := 

"2)  WHY  (does  the  system  waint  this  information)'^"; 

0pts(3)  .The_Length  :==  48; 

0pts(4)  .'rhe_String(l  .  .  64)  :  = 

"3)  HOW  (did  system  get  to  this  point  in  reasoning  process)"^" 
0pts(4) .The_Length  :=  64; 

0pts(5) .The_String(l  ..  46)  := 

"4)  WHAT  (is  the  value  of  attribute  (slot)  X)?"; 

0pts(5) .The.Length  :=  46; 

0pts(6) .The_String(l  . .  59)  := 

"5)  WHERE  (is  object  X  or  attribute  X  found  in  the  system)'^"; 
0pts(6) .The_Length  :=  59; 

0pts(7)  .The.Stringd  ..  35)  :  = 

"6)  EXIT  (the  explanation  facility)"; 

0pts(7) .The.Length  :=  35; 
return  Opts; 

end  Setup _Main_0pt ions _Menu; 


Subroutine  Name:  SETUP_E0P_0PTI0NS_MENU 
Inputs:  None 

Outputs:  Array  of  options  for  the  End-Of-Processing  menu. 
Purpose:  Input  the  menu  options  text  for  the  End-Of-Processing 
menu. 

Notes:  These  options  identify  the  explanation  functions  availabl 
to  the  user  once  the  ES  shell  has  completed  execution. 


function  Setup_Eop_Options_Menu  return  Menu_Options_Type  is 
Opts  :  Menu_Options_Type(l  ..  7); 
begin 

Opts(l) .The_String(l  ..  51)  := 

"**♦**  END-OF-PROCESSING  EXPLANATION  OPTIONS  ♦****"; 

Opts (1) .The .Length  :=  51; 

0pts(2)  .The.Stringd  ..  56)  :  = 

"1)  SHOW  RULE  (show  the  contents  of  an  individual  rule)."; 


0pts(2) .The.Length  :=  56; 

0pts(3)  .'nie_String(l  ..  46)  :  = 

"2)  WHAT  (is  the  value  of  attribute  (slot)  X)'^"; 

0pts(3) .The_Length  :=  46; 

0pts(4) .The_String(l  . .  59)  := 

"3)  WHERE  (is  object  X  or  attribute  X  found  in  the  system)?" 
0pts(4) .The_Length  :=  59; 

0pts(5) .The_String(l  . .  48)  := 

"4)  SHOW  (critical  path  (all  rules  that  fired)  )"; 

0pts(5) .The_Length  ;=  48; 

0pts(6) .The_String(l  . .  46)  := 

"5)  SHOW  (execution  trace  (all  rules  tested)  )"; 

0pts(6) .The_Length  ;=  46; 

0pts(7) .The_String(l  ..  35)  := 

"6)  EXIT  (the  explanation  facility)"; 

0pts(7) .The_Length  :=  35; 
return  Opts; 

end  Setup_Eop_Options_Menu; 
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I  Subroutine  Name:  DISPLAY_A_RULE 
I  Inputs:  None 

I  Outputs:  User  prompt  for  a  rule  number. 

I  Purpose:  Print  the  contents  of  a  specified  rule  to  the  screen. 

I  Notes:  Prompts  the  user  for  a  rule  number.  Searches  the  ES 
I  shell  rule  list  for  this  rule.  Calls  Print _A_Rule  to  output 

I  the  rule's  contents  if  found.  Prints  error  message  if  rule 

I  not  found.  Also  checks  for  invalid  data  entry,  allowing  only 
I  positive  numbers  to  to  be  input.  Re-prompts  user  if  invalid 
I  input  is  received. 

procedure  Display_A_Rule  is 
The_Rule  :  Rules .Rule_Ptr; 

Rule_Num  :  Frames .Rule_No_Type; 
begin 
loop 
begin 

Text_Io . New_Line ; 

Text_Io . Put ("enter  rule  number  to  display:"); 

Rule_Io . Get (Rule_Num) ; 

The.Rule  :=  Rules .Find_Rule(Rule_Num) ; 
if  The_Rule  =  null  then 
Text.Io .New.Line; 

Text_Io  . Put_Line("ERROR:  :  Invalid  Rule  Nuiriber!"); 

Text_Io .Put("  Rule  #") ; 


i 


Rule_Io .Put(Rule_Num,3) ; 

Text.Io .Put("  Not  Found  In  Active  Rule  List'"); 

Text_Io .New_Line(2) ; 
else 

Text_Io .New_Line(30) ; 

Print_A_Rule(The_Rule) ; 
exit ; 
end  if ; 
exception 

when  Constraint _Error  |  Numeric_Error  I  Text_Io .Data_Error 
=>  Text_Io . Put_Line 

("Invalid  entry  ...  enter  a  positive  number  only."); 
Text_Io . Skip.Line; 

Text_Io .New_Line(2) ; 

end; 

end  loop; 

end  Display_A_Rule ; 


I  Subroutine  Name:  DUMP_EXECUTIQN_TRACE 
I  Inputs:  The  execution  trace  to  be  dumped. 

I  Outputs:  The  contents  of  the  execution  trace. 

I  Purpose:  Output  the  contents  of  the  execution  trace. 

I  Notes:  Loops  throught  the  execution  trace  (until  it  is  empty) 

I  and  prints  the  rule  number  of  each  trace  record  and  indicates 
1  whether  or  not  the  rule  "is  pending",  "fired"  or  "failed". 

procedure  Duinp_Execution_Trace  (The.Trace  ;  in 

Tha_Execution_Trace . Stack)  is 
T.Trace  :  The_Execution_Trace .Stack(The_Size) ; 

Temp  :  Exec_Trace_Ptr ; 

Count  :  Natural  :=  0; 
begin 

The_Execut ion_Trace . Copy (The_Trace ,  T.Trace) ; 

Text.Io . New.Line ; 

while  not  The_Execution_Trace . Is_Empty(T_Trace)  loop 
Temp  :=  The_Execution_Trace.Top_Of (T.Trace) ; 
The.Execution.Trace . Pop(T_Trace) ; 

Text.Io . Put ("Rule  #") ; 

Rule.Io. Put (Temp. Curr .Rule. Rule.No,  3) ; 

Text.Io. Set .Col(l5) ; 
if  Temp. Pending  then 
Text.Io . Put ("Pending") ; 
elsif  Temp. Fired  then 
Text.Io.Put("Fired") ; 
else 

Text.Io . Put ("Failed") ; 
end  if; 

Text.Io .New_Line(2)  ; 

Count  :=  Count  +  2; 
if  Count  >=  20  then 
Count  :=  0; 


Wait ; 
end  if  ; 
end  loop; 

end  Dump_Execution_Trace; 


I  Subroutine  Name;  DUMP_CRITICAL_PATH 
I  Inputs:  The  execution  trace. 

I  Outputs:  All  rules  that  have  "fired"  flag  set  =  true, 
i  Purpose:  Print  the  critical  path  the  ES  shell  took  to  arrive  at 
I  Its  decision.  (all  rules  that  were  tested  and  fired) 

I  Notes:  Loops  through  the  execution  trace  (until  if  is  empty)  and 
I  outputs  the  rule  numbers  of  all  rules  noted  as  having  been 
I  fired  by  the  ES  shell. 

procedure  Dump_Critical_Path(The_Trace  :  in 

The_Execut ion_Trace . Stack)  is 
T_Trace  ;  The_Execut lon.Trace . Stack(The_Size) ; 

Temp  ;  Exec_Trace_Ptr ; 

Count  ;  Natural  :=  0; 

First  :  Boolean  :=  True; 
begin 

The_Execution_Trace.Copy(The_Trace,  T_Trace) ; 
while  not  The_Execution_Trace . Is_Empty (T_Trace)  loop 
Temp  ;=  The_Execution_Trace .Top_0f (T_Trace) ; 
if  Temp. Fired  then 

The_Execution_Trace . Pop(T_Trace) ; 
if  First  then 

Text.Io. Put ("GOAL  ==>")  ; 

First  :=  False; 
end  if ; 

if  The_Execution_Trace . Is_Empty(T_Trace)  then 
Text _Io .Put ("START  ==>"); 
end  if ; 

Text _Io . Put ( "  Rule  #") ; 

Rule_Io . Put (Temp . Curr_Rule . Rule.No ,  3) ; 

Text_Io . New_Line(2)  ; 

Count  ; =  Count  +  2 ; 
if  Count  >=  22  then 
Count  : =  0 ; 

Wait ; 
end  if ; 
else 

The_Execution_Trace . Pop(T_Trace)  ; 
end  if ; 
end  loop; 

Wait ; 

end  Dum.p_Critical_Path ; 


I  Subroutine  Name:  EXPLAIN_WHAT 
I  Inputs:  None 


Outputs:  The  value  of  an  attribute  (slot)  in  the  knowledge  base, 
Purpose;  Print  the  value  of  an  attribute  in  the  knowledge  base. 
Notes;  Prompts  the  user  for  the  name  of  an  attribute.  Searches 
the  knowledge  base  for  this  attribute  name.  If  found,  prints 
the  value  of  the  attribute.  If  not  found,  prints  appropriate 
error  message. 


procedure  Explain_What  is 
Found  :  Boolean  ;=  False; 

The_Slot_Name  :  Frames . Slot_Name ; 

The.Fraimes  :  Frames .  Frame_List_Ptr; 

The_Slot  :  Frames . Slot_Ptr ; 
begin 

The_Frames : =  Frames . Active_Frames ; 

Text_Io .New_Line(5) ; 

Text_Io . Put("Enter  NAME  of  ATTRIBUTE  whose  value  is  desired:  ") ; 
The_Slot_Name  :=  User.Io .Read_Slot_Name , 

Text_Io . Skip_Line; 

Text_Io .New_Line(2) ; 

while  The_Frames  /=  null  loop 

The_Slot  :=  Frames . Find_Slot (The_Frames . This_Frame , 

The_Slot_Name) ; 

if  The.Slot  =  null  then 

The_Frames  ;=  The_Frames . Next ; 
else 

Found  :=  True; 

Text_Io . Set_Col (5) ; 

Text.Io . Put ("The  Current  Value  Of  ") ; 

User.Io . Print _Slot .Name (The _Slot .Name) ; 

Text.Io.PutC  =  "); 

User.Io . Print. Value(The.Slot .Value) ; 
exit ; 
end  if; 
end  loop; 
if  not  Found  then 
Text. lo . Set. Col(5) ; 

Text. I o. Put ("The  ATTRIBUTE  =  "); 

User.Io . Print. Slot .Name (The .Slot .Name) ; 

Text. lo . Put ("  was  not  found  in  the  Knowledge  Base."); 
end  if ; 

Text.Io . New. Line (2) ; 

Wait ; 

end  Explain. What ; 


-I  Subroutine  Name:  EXPLAIN.WHERE 
-|  Inputs;  None 

-|  Outputs:  The  relationship(s)  of  an  attribute  (slot)  or  object 
-1  (frame)  in  the  knowledge  base. 

-j  Purpose;  Print  the  relatinnship(s)  of  an  attribute  or  object  in 
-|  the  knowledge  base. 

-|  Notes:  Prompts  the  user  for  a  name. 


Assximes  it  is  an  object  name 


I  initially.  Searches  the  knowledge  base  for  an  object  with  this 
I  name.  If  found,  outputs  the  parent  and/or  sibling  object(s) 

1  related  to  this  frame.  If  not  found,  assumes  name  is  an 
1  attribute  name.  Searches  for  this  attribute  in  the  knowledge 
i  base  and  if  found,  identifies  the  object  to  which  the  attribute 
I  is  related. 

procedure  Explain_Where  is 

The_Obiect_Name  :  Frames .Frame.Name; 

The_Attrib_Name  :  Frames . Slot_Name ; 

Temp_Object  :  Frames . Frame_Ptr; 
begin 

Text_Io .New_Line(5)  ; 

Text_Io . Put_Line 

("Enter  name  of  Object/Attribute  whose  relationships"); 

Text_Io . Put ("within  the  Knowledge  Base  are  to  be  identified;  ") ; 
The_Qbj ect_Name  :=  User_Io .Read_Frame_Name ; 

Text_Io .Skip_Line; 

Text _Io . New_Line (30)  ; 

Temp_0bject  :=  Find_0bject(The_0bject_Name) ; 
if  Temp_Qbject  /=  null  then 
Text_Io . Set_Col (15)  ; 

Text_Io . Put ("Identifying  the  relationships  of  OBJECT  =  "); 
User_Io .  Print _Frame_NaLme(The_Obj ect.Name)  ; 

Text_Io . New_Line(2) ; 

Print_Member_Of _Inf o(Temp_0bj  ect) ; 

Text_Io . New.Line; 

Pr int .Parent. Of _ Inf o(Temp_0bj ect)  ; 

Text. I 0 . New. Line ; 
else 

The. Attrib. Name  :=  Frames . Slot .Name (The.Obj ect .Name) ; 
Temp.Object  ;=  Find.Attribute(The_Attrib.Name) ; 
if  Temp.Object  =  null  then 

Text. lo . Put. Line("00PS !  Something  is  wrong'"); 

Text. lo . Put ("The  value  input  ...  ") ; 

User.Io . Print. Slot.Name(The. Attrib. Name) ; 

Text. lo . Put ("  ...  was  not  found  anywhere  in  the  KB."); 

Text .lo . New. Line ; 
else 

Text. lo. Set .Col (12)  ; 

Text. lo . Put ("Identifying  the  relationships  of  ATTRIBUTE  =  "); 
User.Io . Print. 31ot_Name(The. Attrib. Name) ; 

Text. lo . New. Line(2) ; 

User.Io . Print. Slot.Name(The.Attrib.Name) ; 

Text. lo . Put ("  is  an  attribute  of  the  Object  =  ") ; 

User.Io . Print .Frame.Name(Temp.Obj  ect . Name) ; 

Text. I 0 . New. Line ; 
end  if ; 
end  if; 

Text.Io . New. Line ; 

Wait ; 

end  Explain. Where ; 


I  Subroutine  Ncime:  EXPLAIN_WHY 
1  Inputs;  None 

I  Outputs:  Explanation  of  WHY  the  information  is  being  requested. 
I  Purpose:  Explain  V'HY  the  system  is  asking  the  user  for  the 
1  specific  information. 

I  Notes : 

procedure  Explain_Why  is 
Curr_Data  :  Exec_Trace_Ptr ; 

Temp_Trace  :  The_Execution_Trace . Stack(The_Size) ; 
begin 

The_Execution_Trace.Copy(Exec_Trace,  Temp_Trace) ; 

Curr_Data  :=  The_Execution_Trace.Top_Of (Temp .Trace) ; 
The_Execution_Trace . Pop (Temp .Trace) ; 

Text.Io . New. Line (30) ; 

Text. lo . Put ("Currently  seeking  value  for  "); 

User.Io . Pr int.Oper and (Curr .Data .Curr. Rule . Consequent .Target) ; 
Text.Io . Put("  of  Object  =  ") ; 

User.Io . Print .Frame .Name (Curr. Data .Curr. Frame .Name) ; 

Text.Io . New.Line ; 

Text.Io  .Put(''Rule  #")  ; 

Rule.Io .Put(Curr_Data.Curr.Rule.Rule_No,  3) ; 

Text.Io . Put 

("  is  the  current  rule  prompting  for  this  information."); 
Text.Io .New.Line; 

Text.Io.  Put.LineC  HOWEVER"); 

Print . Prompt _Rule_Info(Curr_Data,  Temp.Trace) ; 

Wait ; 

end  Explain. Why; 


I  Subroutine  Name:  EXPLAIN.HOW 
I  Inputs;  The  execution  trace. 

I  Outputs:  Explanation  of  HOW  the  system  decided  to  process  the 
I  the  particular  rule  in  question  (the  top  of  the  trace) . 

I  Purpose:  Starting  with  the  first  rule  tested,  explain  how  this 
I  rule  was  processed. 

1  Notes:  A  recursive  routine  that  allows  the  user  to  determine  how 
1  much  of  an  explanation  he/she  desires.  After  each  explanation, 
I  the  user  has  the  choice  of  continuing  with  the  HOW  explanation 
I  or  exiting  this  process. 

procedure  Explain.How 

(The.Trace  :  in  out  The.Execution.Trace . Stack ; 

Quit  :  in  out  Boolean)  is 
Temp  :  Exec.Trace.Ptr ; 

Choice  :  Positive; 

Temp.Trace  ;  The.Execution.Trace . Stack(The .Size) ; 
begin 

The.Execution.Trace . Copy (The.Trace ,  Temp.Trace) ; 


Temp  :=  The_Execution_Trace.Top_Of (The_Trace) ; 
The_Execut ion_Trace . Pop (The_Trace) ; 
if  not  The_Execution_Trace . Is_Erapty (The .Trace)  then 
Explain.How (The.Trace ,  Quit); 
end  if; 

if  not  Quit  then 

Explain_Top_Qf _Trace(Temp,  Temp.Trace) ; 

Wait ; 

Text_Io.New_Line(2) ; 

Choice  :=  Display_A_Menu(Setup_Continue_How_Menu ,  2); 
case  Choice  is 
when  1  =>  null; 
when  2  =>  Quit  ;=  True; 
when  others  =>  null; 
end  case; 
end  if; 

end  Explain.How; 


Subroutine  Name:  EXPLAIN.RUNTIME 
Inputs:  None 
Outputs:  None 

Purpose:  Select  the  appropriate  runtime  explanation  function  and 
execute  it,  based  on  the  users  selection  from  the  runtime 
options  menu. 

Notes:  None 

procedure  Explain.Runtime  is 

Temp.Trace  :  The.Execution.Trace . Stack(The_Size) ; 

Quit.How  :  Boolean  :=  False; 

Option  :  Positive  :=  Display_A_Menu 

(The_Options_List  =>  3ecup_Main_0ptions_Menu, 
Max.Options  =>  6) ; 

begin 

loop 

case  Option  is 

when  1  =>  Display _A_Rule; 

Option  :=  Display _A .Menu 

(The.Options.List  =>  Setup .Main. Options .Menu , 
M2LX. Opt  ions  =>  6)  ; 
when  2  =>  Explain.Why; 

Option  :=  Display. A.Menu 

(The.Options.List  =>  Setup .Main. Options.Menu , 
Max. Options  =>  6) ; 

when  3  =>  The. Execution.Trace. Copy(Exec. Trace,  Temp.Trace) ; 
Explain.How(Temp.Trace ,  Quit .How)  ; 

Option  •=  Display.A.Menu 

(The.Options.List  =>  Setup.Main.Options.Menu, 
Max. Options  =>  6) ; 
when  4  =>  Explain.What ; 

Option  :=  Display.A.Menu 

(The.Options.List  =>  Setup.Main.Options.Menu, 


McLX.Qptions  =>  6); 
when  5  =>  Explain_Where; 

Option  :=  Display_A_Menu 

(The_Qptions_List  =>  Setup _Main_Options _Menu , 
Max_Qptions  =>  6) ; 

when  6  =>  exit; 
when  others  =>  null; 
end  case; 
end  loop; 

end  Explain_Runtime ; 
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Subroutine  Najne:  BUILD_EXECUTION_TRACE 

Inputs:  The  current  frame  being  processed  by  the  ES  shell. 

The  current  rule  being  processed  by  the  ES  shell. 
Outputs:  None 

Purpose:  Build  a  new  execution  trace  record,  fill  in  the  needed 
information  and  push  it  onto  the  execution  trace  stack. 

Notes:  Insures  the  execution  trace  stack  is  not  to  small.  Calls 
Print_Stack_To_Small  to  output  instructive  error  msg  if  it  is. 

procedure  Build_Execution_Trace  (The.Frame  :  in  Frcimes  .Frame_Ptr; 

The_Rule  :  in  Rules . Rule_Ptr)  is 

Temp_Data  :  Exec_Trace_Ptr ; 
begin 

Temp_Data  :=  new  Exec_Trace_Type; 

Temp_Data. Curr_Frame  :=  The_Frame; 

Temp.Data. Curr.Rule  :=  The_Rule; 
The_Execution_Trace.Push(Temp_Data,  Exec_Trace) ; 
exception 

when  The_Execution_Trace . Overflow  =>  Print _Stack_To_Small ; 
end  Build_Execution_Trace ; 


Subroutine  Name:  SET_RULE_FIRED 

Inputs:  The  current  rule  just  fired  in  the  ES  shell. 

Outputs:  None 

Purpose:  Set  the  appropriate  flags  for  the  given  rule  to  indicate 
that  it  has  been  fired  ...  its  antecedent  tested  =  true. 

Notes:  If  the  rule  has  no  antecedent  (therefore  always  true),  the 
execution  trace  is  searched  until  the  trace  record  containing 
the  rule  is  found  and  the  appropriate  indicators  are  then  set. 
If  the  rule  has  an  antecedent,  then  a  new  trace  record  is 
created,  set  equal  to  the  trace  record  for  the  rule  that  is 


-|  already  on  the  stack,  and  this  new  record  is  also  pushed 
-|  onto  the  stack.  This  provides  the  capability  of  showing  (in 

-|  the  execution  trace)  when  a  rule  chcinges  from  a  pending  status 

-|  to  a  fired  status. 

procedure  Set_Rule_Fired  (The_Rule  :  in  Rules . Rule.Ptr)  is 
Temp_Rule  :  Rules .Rule.Ptr  :=  The.Rule; 

Temp_Trace  :  Exec_Trace_Ptr ; 

Temp_Data  :  Exec_Trace_Ptr ; 
begin 

Temp_Trace  :=  Find_Trace_Data(Temp_Rule) ; 
if  Temp_Rule . Antecedent  /=  null  then 
Temp_Data  :=  new  Exec_Trace_Type ; 

Temp_Data. all  ;=  Temp _Tr ace . all; 

Temp_Data. Fired  :=  True; 

Temp_Data. Pending  :=  False; 

The_Execution_Trace . Push(Temp_Data,  Exec_Trace) ; 
else 

Temp_Trace . Fired  :=  True; 

Temp.Trace . Pending  :=  False; 
end  if; 
exception 

when  The_Execution_Trace. Overflow  =>  Print_Stack_To_Small; 
end  Set_Rule_Fired; 


Subroutine  Name:  SET_RULE_FAILED 

Inputs:  The  current  rule  that  just  failed  in  the  ES  shell. 
Outputs :  None 

Purpose:  Set  the  appropriate  flags  for  the  given  rule  to 

indicate  that  it  has  failed  ...  its  antecedent  tested  =  false. 
Note:  A  new  trace  record  is  created,  set  equal  to  the  trace 

record  for  the  rule  that  is  already  on  the  stack,  and  this  new 
record  is  also  pushed  onto  the  stack. 

This  provides  the  capability  of  showing  (in  execution  trace) 
when  a  rule  changes  from  a  pending  status  to  a  failed  status. 


procedure  Set_Rule_Failed  (The_Rule  :  in  Rules .Rule.Ptr)  is 
Temp_Rule  :  Rules . Rule_Ptr  :=  The_Rule; 

Temp_Trace  :  Exec_Trace_Ptr; 

Temp_Data  :  Exec_Trace_Ptr ; 
begin 

Temp.Trace  :=  Find_Trace_Data(Temp_Rule) ; 

Temp_Data  :=  new  Exec_Trace_Type; 

Temp_Data. all  :=  Temp _Trace . all ; 

Temp.Data. Pending  :=  False; 

Thp_Ex^cution_Trace . Push(Temp_Data,  Exec_Trace) ; 
exception 

when  The.Execut ion .Trace .Overflow  =>  Print_Stack_To_Small ; 
end  Set_Rule_Failed; 
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-I  Subroutine  Name:  CLEAR_EXECUTION_TRACE 
-|  Inputs:  None 


-|  Outputs: 
-|  Purpose: 


None 

Clear  or  re-initialize  execution  trace  stack  =  empty. 


Notes:  None 


procedure  Clear_Execution_Trace  is 
begin 

The_Execution_Trace .Clear (Exec_Trace) ; 
end  Clear _Execution_Trace; 


-I  Subroutine  Name:  ACCESS_END_OF_PROCESSING 
-|  Inputs:  None 


-|  Outputs: 
-|  Purpose: 


None 

Select  the  appropriate  end-of-processing  explanation 


function  and  execute  it,  based  on  the  users  selection  from 


the  end-of-processing  options  menu. 


Notes : 


None 


procedure  Access_End_Of _Processing_Ef  is 
Option  :  Positive  :=  Display_A_Menu 

(The_Options_List  =>  Setup_Eop_Options_Menu, 
Max_Options  =>  6) ; 

begin 

loop 

case  Option  is 

when  1  =>  Display _A_Rule; 

Option  :=  Display _A_Menu 

(The_Options_List  =>  Setup_Eop_Options_Menu , 
Max_Options  =>  6) ; 
when  2  =>  Explain_What ; 

Option  :=  Display _A .Menu 

(The_Options_List  =>  Setup_Eop_Options_Menu, 
Max.Options  =>  6) ; 
when  3  =>  Explain.Where; 

Option  :=  Display_A_Menu 

(The_Options_List  =>  Setup_Eop_Options_Menu, 
Max.Options  =>  6) ; 

when  4  =>  Dump_Critical_Path(Exec_Trace) ; 

Option  :=  Display. A .Menu 

(The.Options.List  =>  Setup. Eop. Options.Menu , 
Max.Options  =>  6) ; 

when  5  =>  Dump.Execution.Trace(Exec.Trace) ; 

Option  :=  Display .A.Menu 

(The.Options.List  =>  Setup. Eop. Options. Menu, 
Max.Options  =>  6); 

when  6  =>  exit; 
when  others  =>  null; 
end  case; 
end  loop; 

end  Access. End. Of .Processing.Ef ; 


Subroutine  Name:  ACCESS _RUNTIME_EF 
Inputs:  None 
Outputs:  None 

Purpose:  Provide  access  from  ES  shell  to  explanation  facility. 
Notes  :  None 


procedure  Access_Runtime_Ef  is 

Choice  :  Positive  :=  Display _A_Menu 


(The_Options_List  =>  Setup_Access_To_Ef _Menu, 
Max_Options  =>  2) ; 


begin 

case  Choice  is 

when  1  =>  Explain_Runtime; 
when  others  =>  null; 
end  case; 

end  Access_Runtime_Ef ; 


end  Ef ;  — body 


Appendix  B 

Generic  STACK  Code 


This  is  the  generic  stack  package  that  is  used  for  the  execution  trace  in  Package  Ef. 
It  was  taken  from  a  library  of  reusable  software  components  developed  b\'  Grade 
Booch. 


-  -  I  3tC**:4C*********«*****34C3t:3tC**********  ****************** 
--|3tc:4e**********************************************Y* 
«-  (  **34e*:tc**:t:3tc 

1  *********  GENERIC  STACK  SPECIFICATION 

-  I  ♦****♦*♦* 

-  -  I  **************** 

--  I  :i)ti^i^:r*:i^*J^i^:^^:^:^******:^if!^i^^Li)iit‘************************ 

generic 

type  Item  is  private; 


*************** 

*************** 

********* 

********* 

********* 

*************** 

*************** 

*************** 


package  Stack_Sequential_Bounded_Managed_Noniterative  is 
type  Stack  (  The_Size:  Positive  )  is  limited  private; 


--  CONSTRUCTORS 


procedure  Copy  (  From_The_Stack:  in  Stack; 

To_The_Stack:  in  out  Stack  ); 

procedure  Clear  (  The_Stack:  in  out  Stack  ); 

procedure  Push  (  The_Item:  in  Item;  On_The_Stack;  in  out  Stack  ); 

—  raise  overflow:  exception  whenever  no  free  space  exist 

—  for  The.Item  in  On_The_Stack 

procedure  Pop  (  The_Stack:  in  out  Stack  ); 

—  raise  underflow:  exception  whenever  The_Stack  is  empty 


--  SELECTORS 

function  Is_Equal  (  Left:  in  Stack;  Right:  in  Stack  )  return  Boolean; 
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function  Depth_0f  (  The_Stack:  in  Stack  )  return  Natural; 
function  Is_Empty  (  The_Stack:  in  Stack  )  return  Boolean; 
function  Top_0f  (  The_Stack:  in  Stack  )  return  Item; 

—  EXCEPTION 
Overflow:  exception; 

Underflow:  exception; 

private 

type  Items  is  array  (  Positive  range  <>  )  of  Item; 

type  Stack  (  The_Size;  Positive  )  is  record 
The_Top:  Natural  :=  0; 

The.Items:  Items  (  1  ..  The_Size  ); 
end  record; 

end  Stack_Sequential_Bounded_Managed_Noniterative ;  —  spec 


i:i’ 


- I  ********3k***)k*5k*****l4e*3fc**3k****l(l****  ;:5*C***lt'*5f'***:*'*''*''*^-t+ft  +  'l^'i''‘'^r-i^1''ri'^  " 

- I  ***************************************************************** 

-  -  I  *****Jtt*****:*c**********  ******♦*♦♦*★♦********★****♦***♦***********♦ 

--  I  *********  *****j(t*** 

-- I **♦♦**♦**  GENERIC  STACK  BODY  ********* 

-- I  *********  ********* 

-- 1  ***************************************************************** 
-- 1  ***************************************************************** 

—  I***************************************************************** 

package  body  Stack_Sequential_Bounded_Managed_Noniterative  is 


procedure  Copy  (  From_The_Stack:  in  Stack; 

To_The_Stack:  in  out  Stack  )  is 

begin 

if  From_The_Stack . The_Top  >  To_The_Stack . The_Size  then 
raise  Overflow; 

else 

To_The_Stack .The_Items  (  1  ..  From_The_Stack . The_Top  )  := 
From_The_Stack .The_Items  (  1  ..  From_The_Stack .The_Top  ); 
To_The_Stack .The_Top  :=  From_The_Stack .The_Top ; 

end  if; 
end  Copy; 

procedure  Clear  (  The.Stack;  in  out  Stack  )  is 
begin 

The.Stack .The_Top  :=  0; 
end  Clear; 


procedure  Push  (  The_Item:  in  Item;  On_The_Stack :  in  out  Stack  )  is 
--  raise  overflow:  exception  whenever  no  free  space  exist 
--  for  The_Itera 
in  On_The_Stack 
begin 

On_The_Stack .The_Items  (  On_The_Stack . The_Top  +  1  )  :=  The_Item; 

On_The_Stack .The.Top  :=  On_The_Stack.The_Top  +  1; 

exception 

when  Constraint_Error  => 
raise  Overflow; 

end  Push; 

procedure  Pop  (  The_Stack:  in  out  Stack  )  is 

—  raise  underflow:  exception  whenever  The_Stack  is  empty 

begin 

The_Stack .The_Top  :=  Natural'Pred  (  The.Stack .The.Top  ); 
exception 

when  Constraint_Error  => 
raise  Underflow; 


end  Pop; 


SELECTORS 


function  Is_Equal  (  Left:  in  Stack;  Right:  in  Stack  ) 

return  Boolean  is 

begin 

if  Left. The _Top  /=  Right . The_Top  then 
return  False; 

else 


for  Index  in  1  . .  Left.The_Top  loop 

if  Lef t .The_Items  (  Index  )  /=  Right . ine_ltems 
return  False; 

end  if ; 
end  loop; 

end  if ; 
end  T  s  _Equal ; 


(Index)  then 


function  Depth_Df  (  The_Stack:  in  Stack  )  return  Natural  is 
begin 

return  The_Stack.The_Top; 
end  Depth.Qf; 

function  Is.Empty  (  The.Stack:  in  Stack  )  return  Boolean  is 
begin 

return  (  The_Stack.The_Top  =  0  ); 
end  Is .Empty; 

function  Top.Of  (  The.Stack:  in  Stack  )  return  Item  is 
begin 

return  The.Stack . The.Items  (  The.Stack .The.Top  ); 
exception 

when  Constraint .Error  => 
raise  Underflow; 

end  Top.Of; 

end  Stack.Sequential.Bounded.Managed.Noniterative ;  —  body 


Appendix  C 
ES  Shell  Code 


The  following  code  represents  those  subroutines  in  the  original  ES  shell  code  th^t 
were  modified  in  order  to  plug-in  the  explanation  facility.  .Added  code  is  identified 
by  bold  faced  type. 


■'•**********************  *********** 

—  *  * 

*  Fire_Rules  *  SPEC  &  BODY 

—  *  ~  * 

—  ************************************ 

procedure  Fire .Rules 
(Frcune 

;  in  Frames  .Frajne.Ptr; 

Rule.List  :  in  Frames .Rule.List.Ptr)  is 

—  I  Purpose:  This  procedure  controls  firing  the  rules  for  a  demon. 
--|  Exceptions:  None. 

—  I  Notes:  None. 


Temp .Rules 

:  Frames . Rule.List.Ptr  :=  Rule.List; 

Current .Rule 

:  Rules .Rule.Ptr; 

Temp. Frame 

:  Frames . Frame. Ptr  :=  Frame; 
begin 

while  Temp .Rules  /=  null  loop 

—  Find  the  rule  pointer  since  only  the  number  is  kept  in  demon 
Current.Rule  :=  Rules .Find.Rule  (Temp .Rules .Rule.No) ; 

—  Incrament  the  rules  tested  count 

Fraunes  .No.Rules. Tested  :=  Fraunes  .No.Rules.Tested  +  1; 


137 


Ef.Build_Execution_Trace(Tenip_Frame,  Current_Rule); 


if  Current _Rule . Inactive  and  then 

Test_Antecedent  (Frame,  Current _Rule . Antecedent)  then 
—  Increment  the  rules  fired  count 
Frames .No_Rules_Fired  ;=  Frames . No_Rules_Fired  +  1; 

User_Io .  Print_Rule_No  (Current _Rule  .Rule_I»'o)  ; 

Text_Io . Put_Line  ("  fired  successfully."); 


Ef.  Set  _Rule_Firecl(  Current-Rule); 


Current_Rule . Inactive  :=  False; 

Fire_Consequent  (Frame,  Current_Rule . Consequent) ; 
Current-Rule . Inactive  :=  True; 

Temp-Rules  :=  null; 
else 

User_Io . Print _Rule_No  (Current-Rule .Rule-No) ; 
Text-Io . Put-Line  ("  not  fired.  "); 


Ef.Set_Rule-Failed(  Current-Rule); 


Temp-Rules  :=  Temp-Rules .Next ; 
end  if; 
end  loop; 
end  Fire-Rules; 


-  3*c;tc*****:^s  +  *:^c**4c#**^********1t**  +  ***  +  ** 

*  * 

*  Get-User-Input  *  BODY 

- ♦  ♦ 

function  Get-User_Input 
(User-Prompt 

;  in  Rules . Prompt -Token-Ptr) 
return  Frames . Value-Ptr  is 

--|  Purpose;  Manage  user  prompts  by  asking  the  desired  questions 
--I  and  returning  the  response  in  the  value  form. 


Exceptions:  None. 


--I  Notes:  None. 


i  •  • 


Result 

:  Frames . Value_Ptr ; 
begin 

Text_Io .New_Line; 


Print-String  (User_Prompt.ProniptJVIsg); 
Ef.Access_Runtime_Ef; 


Print_String  (User_Prompt .Prompt _Msg) ; 

Clpar;  —  clear  the  input  buffer 

Result  :=  new  Frames. Value  (User. Prompt .Prompt_Value . V_Type) ; 
Result . V_Type  :=  User_Prompt . Prompt _Value . V_Type ; 

Read_Value  (Result) ; 
return  Result ; 
end  Get_User_Input ; 


*  * 

*  Print.Menu  ♦  BODY 

*  * 

procedure  Print_Menu 
(Knowledge_Base_Loaded 
:  in  Boolean)  is 

--|  Purpose:  Rountine  used  to  print  the  user  menu  to  operate  shell. 
--|  Exceptions:  None. 

--|  Notes:  None. 


begin 

Text_Io .New_Line  (25); 

Text.Io . Set.Col  (12); 

Text _Io. Put ("EXPERT  SYSTEM  SHELL  MAIN  MENU"); 
Text_Io .New_Line  (2); 

Text_Io . Set.Col  (8); 

Text_Io .Put("l)  Load  and  Run  Knowledge  Base."); 
if  Knowledge_Base_Loaded  then 
Text.Io .New_Line  (2); 

Text_Io . Set_Col  (8); 


Text_Io .Put("2)  Print  Frames  to  a  disk  file."); 
Text_Io .New_Line  (2); 

Text_Io . Set_Col  (8); 

Text_Io . Put ("3)  Print  Rules  to  a  disk  file."); 
Text_Io .New_Line  (2); 

Text_Io . Set_Col  (8); 

Text_Io . Put ("4)  Print  Statistics  to  screen."); 
Text_Io .New_Line  (2); 

Text_Io . Set_Col  (8); 

Text_Io .Put("5)  Print  Single  Frame  to  Screen"); 
Text _Io . New_Line  (2); 

Text_Io . Set_Col  (8); 

Text_Io . Put ("6)  Reload  the  Frames  and  Rerun"); 
Text_Io . New_Line  (2); 

Text_Io . Set_Col  (8); 

Text_Io . Put ("7)  Exit  Shell"); 


Text_lo.New_Line  (2); 

Text  _Io.  Set  _Col(8); 

Text_Io.Put(”8)  Access  End-Of-Processing  EE”); 


end  if  ; 

end  Print .Menu; 


+  * 

--  *  Shell  *  SPEC  &  BODY 

★  * 

with  Text.Io, 

Fraimes , 

Rules , 

User.Io , 

K_B_File, 

Ef , 

Knowledge.Base ; 


procedure  Shell  is 

--|  Purpose:  Calling  routine  to  begin  execution  of  the  shell 

-I 

--|  Exceptions:  None. 

--  i 

--I  Notes: 


function  "="  (X,  Y  :  in  Frames .Frame_Ptr)  return  Boolean 
renames  Frames. 

Choice 

:  Character; 

Desired_Frame 

:  Frames . Frame_Name ; 

Desired_Frame_Ptr 
:  Frames . Frame_Ptr ; 

Knowledge _Base_Loaded 
:  Boolean  :=  False; 

The_Name 

:  String  (1 . .80) ; 

The_Size 
:  Natural; 

begin 

loop 

User_Io . Print_Menu  (Knowledge_Base_Loaded) ; 

Text_Io .New_Line  (2); 

Text.Io . Set.Col  (4); 

Text_Io.Put  ("Enter  Choice  =>  "); 

Text_Io.Get  (Choice); 

if  not  Knowledge_Base_Loaded  and  Choice  /=  '1'  and 
Choice  /=  then 
Choice  : =  'O’; 
end  if; 

—  clear  input  stream 
Text_Io . Skip_Line ; 

case  Choice  is 
when  '0'  => 

Text_Io . Put_Line  ("No  Knowledge  Base  Loaded  in  shell, 
when  '1'  => 


Ef.CIear-Execution-Trace; 


Knowledge_Base . Build_Knowledge_Base ; 
Knowledge_Base_Loaded  ;=  True; 

Text.Io . Skip.Line ; 
when  '2'  => 

Text_Io . Put_Line  ("Open  an  output  file."); 
Taxt.Io .  Put_Line  ("Printing  the  freunes  ...  ")  ; 
User.Io . Get_File_Name  (The_Name,  The.Size) ; 
K_B_File . 0pen_0utput  (The_Name,  The.Size) ; 
User.Io . Print _Active_Frames ; 

K_B_File . Close.Output ; 


Text.Io . Put.Line  ("Output  file  closed."); 
when  '3'  => 

Text_Io . Put_Line  ("Open  an  output  file."); 

Text_Io . Put_Line  ("Printing  the  rules  ...  "); 

User_Io . Get_File_Name  (The.Name,  The.Size) ; 

K_B_File . Qpen_Output  (The_Name,  The_Size) ; 

Text.Io . Put_Line  ("Listing  of  the  active  rules."); 
Text_Io . New_Line  (2); 

User_Io . Print_Rules(Rules . Active_Rules) ; 

K_B_File .Close_Output ; 

Text.Io . Put_Line  ("Output  file  closed."); 
when  '4'  => 

User_Io . Print _Stats  (Frames .No_Rules_Tested , 

Frames .No_Rules_Fired) ; 

when  ' 5 ’  => 

Text_Io.Put  ("Enter  the  fraime  name  =>  ")  ; 

Desired_Frame  :=  User_Io .Read_Frame_Name; 
Desired_Frame_Ptr  :=  Fraimes  . Find_Frame  (Desired_Frame)  ; 
if  Desired_Frame_Ptr  =  null  then 
Text_Io . Put .Line 

("Selected  Frame  Name  is  not  on  the  active  list"); 
else 

User.Io . Print _Frame_Contents  (Desired_Frame_Ptr) ; 
end  if ; 

Text.Io . Skip .Line ; 
when  ' 6 '  => 

Ef.  Clear_Execution_Trace; 


Knowledge.Base .  Reload.?’ names ; 
Text.Io . Skip. Line; 
when  '7'  => 
exit ; 

when  ’8’  => 

Ef.Access-End-Of-Processing-Ef; 


when  others  => 

Text.Io . Put .Line  ("Bad  Menu  number  entered."); 
end  case; 

--  Delay  for  readibility 
Text.Io .New_Line(2) ; 

Text.Io . Put. Line  ("Return  to  continue..."); 

Text.Io .Get. Line  (The.Name,  The.Size) ; 
end  loop; 
end  Shell; 
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